From your requirements that you state in your comments, you are not looking for a "honey user" but a high-interaction honeypot.
High-interaction honeypots, like the one you are suggesting, must never, ever be run on production systems. Any OS-level vulnerability can enable the attacker to escalate.
Always place high-interaction honeypots on their own walled systems.
But a high-interaction honeypot is only required to gather certain types of info about the attacker. If you are looking to analyse techniques, tools, and gather any other data that can only come from observing the actions of the attacker in real time, then you need a high-interaction honeypot. And then this is not simply a "honey user" as your title suggests, but a full-blown honeypot.
A true "honey user" should not, and need not, be high-interaction. Any attempts to log in as that user can trigger alarms and additional logging. Any use of the user credentials in the system can also be captured. None of these things requires that the credentials actually work, hence there is no security impact. You can capture timestamps, source IPs, and the passwords that have been attempted.
What you are really looking for is Kippo/Cowrie (which I regularly run and have done many presentations on). And the developers are very clear to never run their honeypot on a production system. For the honeypots that I have deployed, I always place them in DMZs, on virtual machines, that reset every 24 hours (or sooner) and the logs are shipped to a central server. Any traffic initiated from the honeypot is blocked. Attackers can get in, but cannot get out, even if they compromise the entire machine.
You should be thinking about a similar setup.