If you want to ensure that users only have access to their files by providing a key (possibly stored in memory so they don't have to provide it over and over again), then why don't you just use a plain, unencrypted filesystem and encrypt each file individually?
Maybe because this leaks information about number of files, creation and modification dates, file sizes and possibly file names if you don't encrypt them. So you start writing some code around that solution and finally you end up with a solution which stores individual files in a container so that you have control over the file metadata.
And now you've reinvented LUKS, TrueCrypt,VeraCrypt, ...
The one difference between your system and these solutions is that your system supports individual keys for each user while LUKS & Co just use a single key. But you can get almost the same behaviour from LUKS by creating a single container per user. You still have the problem that if someone gets root access to the machine, he can read all the open containers.
However, he can also do that when each file is individually encrypted. You need an interface to your system which takes a user and a filename, decrypts the file on the fly using the users key, which sits in memory, and returns the decrypted file contents. What's to stop root from using this same interface, masquerading as the user?
Basically, LUKS below a standard filesystem provides the interface you'd have to design yourself otherwise. There are only two solutions I can see that would give you more security (but not what you envision):
Use a TPM to protect the user keys. This way they won't be stolen from memory, but a user who has root can still masquerade as another user and decrypt every file by ordering the TPM to decrypt its contents.
Put the encrypted data and an access API on a dedicated machine which only serves your application and is only accessible using the access API. This makes for a much smaller attack surface on your encrypted data. But it also can't protect you from a compromised root account on your app server or the storage server.
So, to sum up: I think you already get what you want out of the box with LUKS. There is no secure line of defense against compromised root.
