After a long time of having mixed feelings about it, I've recently become fond of the idea of allowing email addresses as OpenID identifiers. The EAUT project is writing a specification for mapping email addresses to HTTP URLs, which then allows Yadis and traditional OpenID service discovery to be carried out on the HTTP URL in place of the email address.
Their current approach to using this with OpenID puzzles me, however. It seems that they've put the email-to-URL mapping right at the beginning of the process, conceptually "before" OpenID, meaning that OpenID never sees the email address. It would seem far more sensible to me to put the email-to-URL mapping in the discovery phase, so the user's OpenID identifier is their email address.
This enables a nice signup experience on RPs: In the best case, the user provides an email address whose provider supports OpenID, in which case you can authenticate the user and validate his email address all in one transaction. If the email provider doesn't support OpenID, you do traditional email validation, and at the validation URL ask the user to choose a local password. When the user returns and signs in a second time, their provider might well now support OpenID in which case the "upgrade" experience from local account to OpenID account is far less clumsy, because you already know which local account belongs to the user.
For me, this optimized enrollment/upgrade flow is the main selling point for email addresses as identifiers, and is the only motivation I have to set up EAUT for my vanity domain. I think it'd be a shame to miss out on this by doing email-to-URL mapping too early and taking the OpenID protocol out of the loop. At it's core, OpenID supports any URI scheme if you can define a suitable discovery mechanism for it, as we've seen with XRI support.
Let's let OpenID do what it's good at -- verifying ownership of URIs -- and use it to fix the horrible user enrollment user experience that exists today. As a nice side-effect, we'd increase the value proposition for RP implementations, which can't be a bad thing.