To initiate a key exchange using the SRP protocol the client sends the username so the server can look up the salt and password verifier. Is there a simple way to change this so that an evesdropper cannot discover the username?
I think an additional Diffie-Hellman could take care of that, but the SRP protocol is so similar I wonder if there is a way to merge that in without much overhead.
Diffie-Hellman would not help here: an active attacker could use a classical MITM and see whatever data is supposed to be protected by the DH key. He would only see the SRP exchange "from the outside" but would still learn the username.
The non-anonymity of the connecting user is a rather fundamental property of Password-Authenticated Key Exchange algorithms. Such protocols resist offline dictionary attacks because both parties make password-specific commitments in the early stages of the protocol.
In SRP, the server is supposed to choose a random b, and send B = v + gb to the client. A fake server does not know v but would like to learn it, because knowing v allows for an offline dictionary attack (namely, "trying" passwords until one matches, on the attacker's own computer, without interacting anymore with the user or the real server). However, due to the difficulty of the discrete logarithm, an attacker cannot know both v and b which match a given B, unless he chose v and b and computed B from those values. The attacker cannot look back at his past message and think things like: "well, let's assume that instead of the v I used, I should have used v' because that's what the client might have understood"; if he does, then he loses knowledge of b, and without knowledge of b he is "outside" of the subsequent Diffie-Hellman exchange (SRP is still, at its core, a Diffie-Hellman with bells on). In that way, B is a commitment: the server commits to a given password-dependent value v when it sends B, because it will not be able to get any useful information from the rest of the protocol unless he keeps on using that exact value of v. This is were the PAKE magic occurs: this commitment makes sure that an attacker must interact with either the user or the real server or both for every password that he is guessing. This severely lowers efficiency of dictionary attacks, and that's the point of PAKE protocols.
Since the server must commit to a given password-dependent value at the beginning of the protocol (before the authentication has actually occurred), the server must know which password we are talking about, hence a user identifier sent "in the clear".
To preserve user anonymity with regards to eavesdroppers, the server must first be authenticated by the client in a user-independent way, which is what you get from a basic TLS tunnel with server certificates, but if you use SRP, isn't it precisely to avoid using certificates ? Also, in an Internet-related setup, the eavesdropper will still learn the user IP address, which is almost as good as a name in many cases.
If you just want to defend against a passive eavesdropper, then there is a simple way: set up a encrypted connection between the client and the server, and then send all of the SRP messages over this encrypted connection.
In practice, a pragmatic approach would be to set up a SSL connection or a VPN between the client and server, and send everything over this encrypted tunnel. If the client doesn't check the server's certificate, then this is secure against passive eavesdroppers but not against an active attacker (a man-in-the-middle).
If the client does check the server certificate, then this will be secure against active attackers and MITM attacks, too (up to the client's ability to verify the server's cert).
You can always protect content (even login credentials) using encryption, usually transport encryption such as SSL.
Rolling your own crypto base using DH or something similar is generally a bad idea; using something established (again, such as SSL) helps protect you against pitfalls you might not have anticipated. For example, the problem with doing symmetric encryption with a DH generated key is that it's encryption without authentication. The client has a secure connection to someone, but he doesn't know if that someone is the server or if it's a MITM attacker. The certificate-based authentication in SSL protects against that possibility.
So, establish an encrypted connection from client to server, using either a publicly-signed certificate for general-purpose usage, or generate your own signing cert if your application is the only client. Then, once the encrypted link is established, THEN send your login credentials, etc. And you might as well KEEP the encrypted connection going after that, since the overhead is minimal and the increased security is significant.
