If this is for an enterprise, I am surprised that you don't have a single sign on facility (or several) to use. That would be my suggestion. In my experience, it is not common to have applications sharing a database, even for authentication. The thing that gets me here is that it is another enterprise system reinventing the wheel with user authentication, another set of passwords to remember, etc.
Authentication is typically provided either by a web service call (SOAP), or using SSO, and sometimes using a message queue.
By having a separate database you are enforcing a separation of concerns, and you can keep your data to yourself. My suggestion would be if at all possible (which it's not always due to enterprise bureaucracy) to expose the user account management as a service.
If thats not possible and you do have to work with the constraint of the existing database, I would suggest your domain model includes the authentication tables.
In terms of dealing with data that has been changed, the easiest solution will probably to be maintain a session variable such as LoggedInDateTime that caches the value of DateTime.Now (assuming .NET and SQL Server, adjust as necessary), and have an update stamp on your user rows that have a trigger set to automatically update the stamp on an update. Then, for each request check whether the UpdateStamp has been updated since you logged in.
In terms of checking if the user is deleted, per request check that the user row still exists (if using physical deletion) otherwise check for a DeleteStamp or IsDeleted value.
As Robert noted in a comment, I really don't think you can fully encompass all your design constraints in one place. Since you mention that you're intending to document your design constraints to assist with your design decisions, I'm assuming you are working in a waterfall-style development environment. See the Criticism section on Wikipedia regarding waterfall development - while waterfall development may be justified in some cases, there's a reason why agile development is catching on. Since you are free to start developing a product in small increments, as soon as you find that something doesn't work, you throw out that piece and then try a different approach. It's also much more reactive to changing requirements over the course of a project.
Waterfall development often wastes lots of administrative time up front - how many of us have had to deal with a requirements document that is many dozens of pages long, only for it to be essentially useless towards the end of the project, since the requirements have changed over the course of its development?
So far, I haven't directly answer your question regarding how to document a design constraint; rather, I'm suggesting that you don't do it all up front. You don't describe what your development environment is like (meaning, if it's in a large company, you're self-employeed, etc.), but if you can change the expectations of what needs to be delivered up front before any development is done, I think that will help you enormously. If I can twist your question into, "What should I document up front?", then I would suggest you look into formulating user stories instead, which should better document the true needs that should be known up front.
(By the way, if you are working on a solo or small team, you would also benefit from reading up on lean development, which emerged from the Agile movement, and further focuses on removing waste from the development process).
Edit, based on Nicholas' comment:
It sounds like you are probably in a tough spot. The above links in my answer cover each of those areas that you're not familiar with (jump to the top of the Criticism link to see the full scoop on Waterfall development - if you're not familiar with Waterfall versus Agile development, it's almost certain you are doing the former).
Do you have a feeling for how flexible your management's expectations are for what a development project entails? If you feel comfortable bringing the idea up to them, I think you would really benefit from a lean technique, though admittedly, without having a person experienced in lean development there to guide you along, you might find it daunting at first.
If, by chance, you have a Pluralsight subscription (or don't mind signing up for the free trial), their course called "Best Practices for Software Startups" covers the principles behind lean development and would give you arguments to bring to your management as to why you shouldn't try to plan all these design constraints right from the start of a project. (Alternatively, there are a number of presentations you can watch on YouTube).
Best Answer
The way this is normally done is with user roles and a role access matrix.
Each user has a role, saved in the database along with the user name, password, etc.
Then, there is a two-dimensional role access matrix somewhere, specifying for each role and for each screen field what kind of access is to be had by users who have that specific role on that specific screen field. The access may be:
In a variation of this scheme, each user can have multiple roles, so the access that a user has to a certain field is computed to be the maximum access permitted by any of the roles held by the user. When this variation is used, the 'roles' may be called 'groups', in the sense that a user may belong to several groups simultaneously.
In yet another, more sophisticated but even more complicated variation, we introduce permissions as an intermediate step, replacing the role-access matrix with a much smaller role-permission matrix. In this scenario, each field has a required permission for "read-only" access, and another required permission for "read-write" access. (These required permissions can be hard-coded for each field: they don't need to be configurable.) If a user has a role which has none of the required permissions, the user does not see the field at all. So, for example, an "email address" field may require some "view sensitive information" permission in order to have "read-only" access to it, and some "edit sensitive information" permission in order to have "read-write" access to it. Each user has or does not have these permissions depending on their role. Presumably there will be many fields that will require the same permissions for the same kind of access, so the total number of permissions will be very small, which in turn means that the role-permission matrix will be small.
So, one of these approaches should solve your problem nicely. In fact, I would be willing to bet that they more closely parallel what your client really wants to accomplish: they probably don't want to tailor the type of access of every single user to every single screen field, they probably have some user groups and possibly some field groups vaguely in mind, and they want different groups of users to have different types of access to different groups of fields.
The role-access matrix or the role-permission matrix can be stored in the database, or they can be stored in an external configuration file, or, if you are building your user interface using some scripting language like PHP, they can even be placed directly in the code, and let the customer modify the PHP source file to alter the permissions.