The original SRP specification used H(s,P) for a not-thoroughly-specified password derivation scheme, which includes the salt and the password together (but not the identity). The first draft for RFC 2945 (that's SRP-3, predecessor to SRP-6) already includes the user name in the hash.
Usually, the inclusion of the user name in a password derivation scheme is meant to simplify security proofs; with the inclusion of the user identity, one can study the security of SRP without having to bother (much) with what happens when an attacker plays tricks between a server and several clients (e.g. tricking two users into talking to each other, each one believing that the other is the server). Protocols with more than two parties are exponentially more difficult to analyze; the user name as part of the hash makes the security of the whole thing simpler (which does not mean simple, only possible to study).
Therefore, implications of omitting the user name from the hash are, at best, not investigated. So, do not do it. This is also the general advice about cryptographic algorithms and protocols: do not fiddle with them, because security is a subtle thing and you cannot know, by yourself (even if you are a competent cryptographer), if you still have it or not after any minor modification (it takes a lot of competent cryptographers to know that).
For your specific problem, I would advise registering several "users" for all the identifiers that the user may wish to use, and logically link them to the same identity once the protocol has run.