Right now, it seems that none of the existing major browsers supports TLS-PSK, and neither to they support TLS-SRP. In your case, both are applicable, but SRP is "stronger" in that it tolerates much better a low-entropy shared secret (say, a password). There has been some initial effort at making Chrome SRP-aware; I don't know how far it went. Since everything PSK offers can be done by SRP and arguably in a better, stronger way, it is plausible that browsers will get SRP support before they get PSK support. But it is not done yet.
In the meantime, you can have some partial workarounds:
Have your users employ Firefox, with a specific profile. A Firefox profile includes, in particular, the set of root CA that the browser will use to validate server certificates; let them use an "empty" profile containing only your own CA.
Make the users connect through a VPN. In particular a SSH tunnel: SSH can be used as a SOCKS proxy, which the browser can be instructed to use for every connection. SSH's public-key model is CA-less; each user decides which key he accepts or not.
Turn the Web application into a genuine, full-fledged application installed on the client system. That application will then do the SSL with your server, and can then choose whatever authentication mechanism it wishes to use.
Don't do anything: it is the problem of the client, not yours.
The last "workaround" deserves some extra thinking. Indeed, the problem with potential rogue CA is that these CA are trusted by the client. In a successful Man-in-the-Middle attack, the attacker poses as a fake server, and the client is talking to the attacker, not to you. Therefore, as first approximation, there is nothing you can do in the server which will change what happens between the client and the attacker. In SSL/TLS, the client announces all the cipher suites it is willing to use, and the server then selects one. Even if your server wants to use SRP or PSK, you can bet that the attacker's server will prefer some other cipher suite.
Therefore, assuming that you find an SRP-aware browser, the security of the connection against MitM attackers (who could bribe a CA) relies not on your use of SRP on your server, but on the human user: that meat-bag must expect SRP (or PSK) and call foul play if he does not get it. MitM will be defeated only insofar as the human user, presented with a green padlock and nice login page with your logo and asking for his SMS-obtained password, will say to himself: "hey, this is a Web page, not a browser popup !" and then refuse to connect. If you can make your users reliably react that way, then you can probably train a cat to do the laundry and vacuum-clean the carpets (and then I am highly interested in your services).
This amounts to the slightly depressing following summary: if your users trust rogue CA, then they are already hosed; and there is nothing your server can do to really protect them. First step is to teach them to un-trust existing CA, which will bring back protection (assuming their machines are not already hijacked), but will also "break the Internet" from their point of view.
