What I'm suggesting is that secrecy is a useful layer on top of a valid cryptography approach.
What you can do is that you can have the inputs to your hash function come from several places. User password, a salt per-password to protect against rainbow table attacks, a pepper forces an attacker to get both the application code, AND the database dump.
So it's bcrypt(password + salt + pepper). If you don't know the pepper, all of a sudden you have a 128+ character totally random password to break, instead of the user's totally insecure '12345'.
And in the case that you have the application code broken (ie, attacker gets the production code), well, then you're still using bcrypt, so no problem.
That step would protect against the common "db dump stolen off a dev's laptop" attack. Since the pepper only exists in production.
So yea, you're right that you can't just make shit up and hope for the best. But separating the data that needs to be stolen strengthens your overall defense.
Suppose you're doing the byte shuffling right? Or you split the hash value in two and you concatenate them in the reverse order, something like that.
Now here's the thing: if you have a determined attacker, they will figure out your code does that. So you gain no extra security from it
For a casual attacker this may be a bigger deterrent. Now, this casual attacker may try to create (or already has) an account, for which the password is known. So he goes and compares it trying to figure out your encryption mechanism
It's slightly more difficult than the guy that just used MD5 to hash the passwords (let's assume that's the minimum security people use - "in theory")
So, it's all fine and dandy until you have another 'increase the security' idea that actually decreases the security. And this is more common than you think.
Example: taking the hash and encrypting it (for some choices of hash and encryption)
(Not to mention when people think that because they use this 'improved security scheme' that they invented they can be lax in security elsewhere in the chain)