Whenever you have an external authentication mechanism, there must be a common key used by both systems to identify users. Typically for Liferay the screen name becomes the key as it works for many external systems such as LDAP, SiteMinder, etc.
"complete flexibility of screen names" is then not possible because you break the connection between the external auth and Liferay.
Now the OOTB authentication mechanism works this way, but that doesn't mean it is the only way. You can build out an auto login hook to handle the login side that would break you out of the screen name binding, but you become responsible for enforcing a "required" status on whatever the auto login hook is using.
NTLM, for example, uses a servlet filter for the NTLM authentication workflow and at the end it sets a request attribute using the user account. It also has an auto login hook which will use the request attribute, if present, to identify the user that should be logged in. Put together, the two pieces work in concert to authenticate a user without violating aspects of the authentication process.
Not sure what you mean by customer data, if you're talking about user accounts too bad. A user record is required for all authenticated users as it provides the foreign key for every other table in the system that is tied to user tracking or ownership.
I have seen where a custom external FK value is stored as an expando value for the user and a service wrapper is used to weave together LR and external data in the User so as to not replicate data, but this can prove to be taxing when retrieving user lists. It's best to let Liferay own LR data and you reach out to external systems for non LR data on demand.
