Wow. Just wow. I NEVER learn anything from /. comment threads, especially about security (I would argue that nobody does, because most of what's said is wrong), and I think I just did!
It's worth noting that this benefit relies on your application server not being compromised, as if an attacker owns that, they can change code to move the client-based hash step to the server (changing the client AND server code), and still see passwords. So you're really only protecting against network-sniffing attacks, which are USUALLY prevented by SSL anyway. This actually gives me an idea, but I'll have to think about it. Something along the lines of using an MD5 of the sign-in page itself as a part of the process, so changing the page will break things. That's obviously vulnerable to exactly the same attack, but perhaps there's an extension to this which might work.
You have also prevented plain-text reveal in the situation where someone somehow intercepts the post-SSL stream but can't alter the application, which is certainly a possible scenario.
There's a major benefit, with this scheme, if you're using a dedicated ssl server and relying on a secure network behind that (which is not uncommon in higher-load applications) - compromise of the ssl server doesn't lead to compromise of plain-text passwords. The attacker would need to take the next step and own the application servers behind that, and given that this scenario only crops up in high-volume load-balanced systems, there are likely lots of identical systems to deal with, and (hopefully) switched-on administrators and security experts, so adding another step like that could vastly decrease the chance of a complete compromise. The attacker would already own login details to the attacked site (they could replay hashes from the owned SSL appliance), so there's every chance they'll take that and never even try to compromise the application code itself, thus never leading to the plain-text reveal.