Ok. This problem has been resolved. The issue was this: These two tables "dbo.UserPortals" and "dbo.UserRoles" were missing certain key table properties, contraints and indexes and foriegn key information. We did a compare on table properties of our broken DNN database to a working one and found the descrepancies, made the changes, and then verified (and cleaned up) any orphan data that existed.
When we first attempted our uninstall of the MPUS_X module, it failed halfway down the process. I guess these table properties were affected and didn't get reset back to the default way of doing things.
I guess though this does present a question to the DNN Core Developers regarding this portion of my original email -
"When we look in the database, we can see that the user has been created in the following tables: dbo.aspnet_Membership, dbo.aspnet_Users and dbo.Users. However, we do not see the user (userid) in the dbo.UserPortals table. This of course does not allow the user to be display in the list of users in the DNN portal. If we manually create a record in the dbo.UserPortals table, the user will show up in the displayed list, but of course the normal registration process that would have assigned him his default roles have also not been created."
Should not the entire "registration" process (meaning the creation of all the records in all the tables - Users, Roles, Portals, etc.) be wrapped in some kind of method that would prevent the creation of data in some tables, while failing to do so in others, especially when the registration process fails and returns the messgae "An Unexpected Error Occurred During Registration. Please Contact The Portal Administrator For Futher Information."
Thanks for you time.