SRP does DH key exchange with authentication, and has the capability to also authenticate the server as well (though usually the server is authenticated by keeping the verifier secret). If the key is generated strictly from a password and salt, with the salt stored on the server, you can do a dictionary attack on the verifier (e.g. if the server is compromised or the server is malicious), but there are ways to strengthen resistance to that.
Without doing a (fairly expensive) dictionary attack, the server never sees the password, and there are various possibilities to make a dictionary attack infeasible.
Update to answer updated question:
If the algorithm is known, the site-specific key is just as susceptible to a dictionary attack as any other scheme.
You could use a two-password method to make it infeasible to do a dictionary attack.
Example:
$MasterKey = HMAC(MasterPassword, Identity)$
$SiteKey = HMAC(MasterKey, Password, SiteIdentifier)$
where $Identity$ can be anything you want (e.g. e-mail address, SS#, nickname). I'm using $SiteIdentifier$ as some form of persistent identity. Domain name may not be stable enough, so either some sort of GUID or a public key or something could be used.
The $MasterKey$ could also be derived from a value stored on a key-server or on a specialized device (perhaps still in combination with a master password). There are many possibilities.
$SiteKey$ could be used directly as the secret key in a protocol like SRP, or turned into a typable password in the same way a random password generator works.
With SRP, the protocol for the standard implementation has a salt that's supplied by the server, and could be used instead of $Password$, or just generate a typable password and combine that with the salt as usual (though the need for a salt is eliminated with a random password, that would allow using the password with other implementations of SRP by typing in the generated password manually).