I think I have found the solution to all of my problems.  And for everyone else, this will probably be pretty good to know...  (FYI - this testing was done on DNN v4.05.03.)

In a test environment, I created users and then changed the User Settings to use "[USERNAME]" as a token to replace the "Display Name", inheritly hiding the "Display Name" fields.  Then, I ran the source through debug and noticed that the DisplayName property was indeed returning this value directly from the UserInfo object.  So, that led me to look more closely at the UserInfo class.  When I removed the token from User Settings, the "Display Name" fields were all returned to normal, but they still had the tokenize values.  This led me to initially believe that the database was updated to reflect the token change (but I later found that this is a cache issue).

When I checked out the actual DisplayName property in the source, there was nothing out of the ordinary.  The property was simply returning a private object value.  The constructor had nothing out of the ordinary going on either.  However, there was another method in the class that caught my attention:

Public Sub UpdateDisplayName(ByVal format As String)

 'Replace TOKENS
 format = format.Replace("[USERID]", Me.UserID.ToString())
 format = format.Replace("[FIRSTNAME]", Me.FirstName)
 format = format.Replace("[LASTNAME]", Me.LastName)
 format = format.Replace("[USERNAME]", Me.Username)

 DisplayName = format

End Sub

As you can see, there is a method that is not changing the value in the database, but just replacing the value using one of the other properties.  When I removed the User Setting token, the UserInfo object was still in cache.  In order to fully restore this, you would need to perform an action that releases the cached objects (IIS restart, web.config change, restart application, recycle app pool, etc.).

Also, be sure to note that although this is not widely documented, you are limited to the four tokens you see in the method above.

In order to solve my specific issue and to meet my project requirements, I am going to go into my custom membership provider and put the DisplayName property back the way I want it, while still allowing the DNN Core to remove the "Display Name" fields using the token in "User Settings".  Although I have not implementing this yet, I am sure that this will work!  :)

Happy DNNing!

Here I am multiple-posting...  But in this case, it is worth it.  It appears that the DNN core code does nothing if you specify a token that it doesn't recognize.  (Duh!)  However, upon seeing that the token is specified, it replaces all DisplayNames in the database with the value specified with the token (only the four tokens that it recognizes). 

If you for some reason decide that you do not like to use the token, removing it will not return the Display Names to their original values.   I repeat...  DNN does not archive or otherwise save the previous DisplayNames.  If you remove the token, then DNN will use its default Display Name of [FIRSTNAME] [LASTNAME].  This is hard-coded in the DNN Membership Provider.

However, there is an easier fix to my specific problem than what I initially thought was necessary.  First, I used a token of [NOTHING] to make sure that the DisplayNames would not be overridden.  Next, I went into the code-behind of the ~/admin/Users/UserSettings.aspx file and commented out the following code (approximately Line 168):

If key = "Security_DisplayNameFormat" Then
    'Update the DisplayName of all Users in the portal
    Dim objUserController As New UserController
    objUserController.PortalId = UserPortalID
    objUserController.DisplayFormat = setting
    Dim objThread As New Thread(AddressOf objUserController.UpdateDisplayNames)
    objThread.Start()
End If

The snippet we commented out simply checks the key of the UserSettings property editor and if the key matches the string name, it assigns the PortalId and the provided token to the UserController class.  Then, the UpdateDisplayNames method is called, which updates the Display Name of every single user in the specified portal (this method requires the previous two properties in order to call a subsequent UpdateUser method).  Since a portal could potentially have thousands of users, this step is run on a separate thread, which allows the code to continue to run while this step completes.

The Bottom Line...

Commenting out the preceding code and setting the Display Name token to an unknown token ensures that your existing Display Names remain intact, and that all instances of the Display Name field are removed and/or readonly throughout the portal.  All new users will automatically be assigned the Display Name using their First Name, a space, and their Last Name.  That is, unless you have a custom Membership Provider that reassigns this property value.

As specified in earlier replies in this thread, simply add known tokens into the Display Name property of the User Settings.  This will automatically populate the Display Name, and in effect removing it from the registration form.  In the User Account module, it will be displayed as a label instead of a textbox.