Oops - FD ate the first part of my post. Here it is again:
"If the average joe blow logs in with password: bob (an example of course not actually) and the captured password is a ridiculously long hash, at least the user is more protected as their password: bob that they use for every site is encrypted."
Except you've created an extra security issue:
1.) The attacker has the hash and as you mentioned earlier you planned to salt "server side". So, you have an unsalted hash that I can just run against a rainbow table and guess what? Now I have the user's password.
3.) Even if your client side implementation is perfect, you have not eliminated the risk of what happens if the user's hashed password is captured. Since the hash is used for authentication - I don't need the password - I just need the hash to authenticate to this system.
4.) Even if my target isn't this system, but actually the user's password, as I mentioned your implementation exposes the necessary information to perform a rainbow table attack. While salts are not considered information that you need to go out of your way to protect, you don't exactly want to deliver it in to your attacker's hands either.
In reference to SSLStrip - if you're being attacked by someone with the means to intercept the web traffic necessary to carry out this attack, I guarantee your implementation won't protect against them. In fact, you're giving them an additional attack angle that they could do offline.
Summary: If you want to protect against SSLStrip, make your site 100% SSL only and you're done. Avoid protecting against one angle of attack by exposing others.