Using a known salt isn't great, but it still makes extracting the password orders of magnitude more difficult.
Hashed passwords are typically attacked using a rainbow file. Basically you use a dictionary file to hash words from the dictionary file and store the plaintext word and the resulting hash together in a file/db/whatever. After you've hashed every word in the dictionary, you start doing combinations: wordword, wordnumber, wordnumberword, etc... Of course each time your add another element, you're exponentially increasing the time it takes to generate your rainbow file.
Using a multi-character hash is basically adding another element to the password on behalf of the end user. Basically if we say it takes 100 hours (totally made up number, I suspect it's much higher-depending on password rules) to generate a comprehensive enough rainbow file to find an average password, if you add a 1 character alpha numeric salt, it now takes 3,600 hours to find that password. If you add 2 characters, it now takes 129,600 hours. And so on.
Using a public username (and having your attackers know that's what you're using) means that you have to generate a full rainbow file for EACH user. So while it's not as good as a decent sized random salt, you can no longer take 100 hours of work and hope to extract 8,000 passwords from a site's password db/file. You have to do 100 hours of work PER user, and still have a 30-50% success rate. So to get the same 8,000 passwords you'd need to do 1,600,000 hours of work (assuming a 50% hit rate).
So assuming you personally are not a specific target, the site itself is numberOfUsers* more time consuming to extract X passwords from, than a site that just uses MD5 with no salt.
Hashed passwords are not normally attacked with rainbow tables. This is a huge misconception. The overwhelming majority of password attacks are done with iterative password crackers. "Rainbow table" crackers are a recent phenomenon, but password crackers are one of the oldest and most effective tricks in the book.
The salt is "439a". The MD5 hash of a<439a> is "57ec1dc4757768c9961ec5a46eb2a36f". Did that match? No? The MD5 hash of aa<439a> is "91b0655c6ab36ee9fc9fea0bda7f78ab". Did that match? No? The MD5 hash of aal<439a> is "9c9e018c05d4d7a36b31eb17e3b71c7d". Did that match? Yes? You win.
The point is, MD5 is extremely fast. Speed is one of the top 3 design goals of MD5, SHA1, and SHA256.
As I mention in my other post, with current hardware, my understanding is that that type of attack would take on average one year per account.
Obviously strict password rules (minimum length, etc...) shrink the attack space dramatically, but it's still a long time per hash/account. Given the number of sites/applications out there that don't use salts, and hence ARE vulnerable to a 1 hour attack using an existing rainbow file, I'm not sure why a cracker (who isn't targeting your site/app over every other site/app specifically) would bother.
You might direct that question to Alec Muffett, who wrote Crack, and Solar Designer, who wrote John the Ripper, both of which have cracked salted hash passwords for over a decade.
Using RSA directly as a block transform is extremely dangerous; the thing you have to remember about RSA is that, more than most other crypto operations, RSA is just a simple math problem. You are vanishingly unlikely to use RSA directly in your code without introducing a vulnerability.
That said, two responses:
(1) Yes, MD5+RSA is slower (and thus better) than just MD5.
(2) But we're quibbling, because bcrypt is tunably slower, designed specifically for this problem, free, and available for most dev environments.
Hashed passwords are typically attacked using a rainbow file. Basically you use a dictionary file to hash words from the dictionary file and store the plaintext word and the resulting hash together in a file/db/whatever. After you've hashed every word in the dictionary, you start doing combinations: wordword, wordnumber, wordnumberword, etc... Of course each time your add another element, you're exponentially increasing the time it takes to generate your rainbow file.
Using a multi-character hash is basically adding another element to the password on behalf of the end user. Basically if we say it takes 100 hours (totally made up number, I suspect it's much higher-depending on password rules) to generate a comprehensive enough rainbow file to find an average password, if you add a 1 character alpha numeric salt, it now takes 3,600 hours to find that password. If you add 2 characters, it now takes 129,600 hours. And so on.
Using a public username (and having your attackers know that's what you're using) means that you have to generate a full rainbow file for EACH user. So while it's not as good as a decent sized random salt, you can no longer take 100 hours of work and hope to extract 8,000 passwords from a site's password db/file. You have to do 100 hours of work PER user, and still have a 30-50% success rate. So to get the same 8,000 passwords you'd need to do 1,600,000 hours of work (assuming a 50% hit rate).
So assuming you personally are not a specific target, the site itself is numberOfUsers* more time consuming to extract X passwords from, than a site that just uses MD5 with no salt.