In beta 3 (including refresh) and earlier, work items have always been assigned to user names.  For some organizations, that’s a real problem, as the user names do not have any relationship to the user’s real name.  We have fixed this for RTM.  Brian Harry sent the following email about it, and I thought it was worth sharing (substituting Joe Developer for an actual employee’s name).  It’s another example of where customer feedback has had a significant impact on the product.

We went round and round on what to do about this.  For most of the product cycle TFS has used peoples’ aliases everywhere.  I don’t think we even asked the question very hard about whether or not that was the right thing.  It’s what we’ve always used internally and it seemed obvious that’s what TFS would use.
 
A few months ago we started hearing  significant feedback from customers that this is not workable.  We did a bunch of research and found that many customers have obtuse aliases like nm39756 and that no one in the organization can recognize them.  Many customer say this was a significant adoption blocker for them.  Working together with customers and trying to balance addressing their issue against the cost of changes at this late point in the product cycle, we decided to make a change.  In version control, build and a few other areas we still use users’ aliases.  However in work item tracking we use display names.  I expect that in a future version we will unify this to make them consistent.
 
It is true that display names need not be unique.  This can cause some confusion, however work item tracking isn’t the only place in an organization where having multiple people with the same display name can create a problem.  It makes address books hard to use, email, etc.  What we do internally is to qualify duplicate names.  For example, there are multiple Joe Developers at Microsoft.  The one in our organization has the display name “Joe Developer (VSTS)”.  This is the “best practice” we will recommend to customers.
 
We investigated adding support for automatically qualifying display names when we import them from AD (for example by using their alias).  However we decided that the solution would require a while (and customer feedback) to get right and decided not to do it in this version.
 
The duplicate display names do not create security problems because all security decisions in the system are made based on the user’s SID and not any of the human readable strings.  Further, the UI we use to manipulate security uses the Windows UI to full resolve user names or works with aliases (which are unique).

I hope this helps you understand where things are and what we recommend to customers.