I think you miss the purpose of a salt trap door encrypted password. The goal for a salted password is to be any reproducible process which does not expose any information about the password and that changes the final digest value so that A: users with duplicate passwords are not apparent, and B to brute force a given plaintext against a database of passwords is takes N (computationally expensive) digest attempts where N is the number of usernames. The salt should be easily guessable, in fact most of the time it is plaintext. What you suggest in your opening paragraph is to create your own digest or encoder -- this is not good idea. LOTS of time and research goes into trap door encryption and digests to make sure that the they are secure -- there is good reason for this. MD5 for example had a ton of eyes looking at it over the years and is only recently broke. I do not know you personally Ted, but I would not bet money on the fact that you could produce a new un-bruteforcable (or even worse yet, un-flat-out-breakable) trap door encryption scheme. At best it would be OBFU. They are very hard to do well.

One (of many) reason almost all secure apps use trap door encryption for passwords is that it is not reversible. That is KEY. One such attack that this defeats is your system administrator, which has access to all of your accounts and passwords, knowing the passwords when he gets laid off next week. To reset or change your password other sources of information are used for verification such as your email address with a click back, or all the way up to physical request in person with multiple forms of ID. Having plain text stores of passwords totally blows the user:pass concept of proving identity. Just think of this: if your server is compromised, and you can determine the break in exploit and time table, with plain text passwords in your database you cant roll back to the pre-exploit time and patch the issue. you have to have everyone on the system reset their password.