You can backup the seed of course, but you're sending it over a socket and it's sitting in your online machine as well. That's an attack surface you should be trying to reduce, not the other way around.
You can run 1 DB and let your users have access to their wallet in GUIs each. The DB also has its own language over the socket, which goes over the FCGI protocol, ie from your end you can display balance and history with HTML/js straight from the DB if you'd like to go down that route. The RPC is fine too.
It does that but you need to elaborate on your requirements and opsec. How many addresses do you expect to use per employee? If it's only 1, just use lockboxes. Do you intent to give your employees signing privileges? If no, then only load watching only wallets in armoryd. It can create unsigned transactions that you can review and sign with an offline GUI/armoryd instance that has the full wallets loaded.
At any rate you are better off just letting armoryd run on watching only wallets and let people sign offline through the GUI, whether it's you or your employees. This model suggests you create the wallets offline and only import the public seed in armoryd.
So the question remains, do you actually need to create full wallets at all from the RPC? Chances are you don't, and shouldn't.