If I use the 2.0 membership system out of the box, then users have to think of a username when they register.  If they forget their password, they can use the "retrieve password" facility be keying in their username.  But what happens if they forget their username?  Do I have to build a custom "retrieve password" facility based on them entering an email?

Wouldn't it simplify matters to force them to use their email as their username?  This prevents them having to think up a good  username, and it avoids the possibility of them forgetting it.

But what then happens if they change their email address?    They could still login using their old one.  And they could change the email address stored in their profile to their  new one.

But can they change their username to the new email address?

I actually am setting up an application to have the username be an email address. In terms of creating and logging in users, it's easy. I templated the login control appropriately (see http://forums.asp.net/993414/ShowPost.aspx) and as far as my Registration page goes, on the CreatingUser event of the CreateUserWizard control I just set the email address to equal the username so that both fields match:

public void RegisterNewUser_CreatingUser(object sender, System.EventArgs e)
{
   CreateUserWizard cuw = (CreateUserWizard)sender;
   cuw.Email = cuw.UserName;
}

As far as updating the UserName (in this case email address), I don't think the MembershipUser class allows it so I'm going to write my own method to accept a string for the old email address (username) and a string for the new one. This will first create a MembershipUser object with Membership.GetUser(oldEmailAddress) and change the Email property to the new value. Then I will execute a sql command to manually go into the aspnet_Users table and change the UserName and LoweredUserName values to the new value for the record matching the old UserName and the ApplicationId.

In theory I don't see any issues with this approach.

I just tried the above approach and it works fine. Please note I'm using the MS Data Application Block and I have the applicationId variable set to the correct application id in the class constructor for the class this method is in. Regardless, you get the idea.

You could also bypass the Membership.UpdateUser and just write your own SQL to update the aspnet_Membership table as well. These tables and the built in classes are handy and wonderful, but there's no reason you can't modify records directly if you need to do something that's not provided for already assuming you aren't doing something that will mess up the built-in plumbing.

public bool UpdateUserNameAndEmail(string currentEmail, string newEmail)
{
   MembershipUser memUser = Membership.GetUser(currentEmail);
   memUser.Email = newEmail;
   Membership.UpdateUser(memUser);

   StringBuilder sb = new StringBuilder();
   sb.Append("UPDATE aspnet_Users SET UserName = @NewEmail, ");
   sb.Append("LoweredUserName = LOWER(@NewEmail) ");
   sb.Append("WHERE UserName = @CurrentEmail AND ApplicationId = @ApplicationId");
  
   ArrayList al = new ArrayList();
   al.Add(new SqlParameter("@ApplicationId", applicationId));
   al.Add(new SqlParameter("@CurrentEmail", currentEmail));
   al.Add(new SqlParameter("@NewEmail", newEmail));
  
   SqlParameter[] pArray = (SqlParameter[])al.ToArray(typeof(SqlParameter));
  
   return (SqlHelper.ExecuteNonQuery(dbconn, CommandType.Text, sb.ToString(), pArray) == 1);
}