Depending in the setup, the person who makes the reservation might also be referenced via the author field in views, but I don't know how your reservation system works.
Properties of other entities can be embedded in a view via the relations in the advanced section. There has to be a common field such as an entity reference linking the two content types together, but author, tags and several other properties can be used as well.
After adding such a relation, New fields will become available in the fields, filter and sorting sections.
I believe there is some misunderstanding about the modules. An entity reference (or any other reference in Drupal) uses the user id (uid) not a custom field #L. So when you add such a reference to a content type, you can only find users by username (or common name if realname module is installed). Since you said you have the customer name this should not be a problem as you select the users by name, but their uid is stored in the database.
Make sure there is only one relation on the content type that is created on the desk (registration). Adding an entity reference on the user (or both content types) makes no sense; a registration is made for one or more users, user's don't own one or more registrations.
Create a view listing fields of the main content type you want to display (registration). Then add a views relationship to the user object via the entity reference field. Finally you can add all fields of the user object to your list of fields.
The only filters you will need are filters for limiting the set of registrations (you could add contextual filters to list registrations per user), but I'd leave out all registrations to start with. You can always add them later.