Using the idea of having executable code in a text box and trying to execute it violates SO many principles of good programming that I don't know where to begin. But I'll try.
First and foremost, the ability to inject code into an app would allow someone to undo, for example, the steps you take to hide the ribbon and navigation pane. It would allow someone to do a "CurrentDB.Execute 'DELETE * FROM table';" if you allowed unscreened access to such a facility. If someone decides to run an update query to add 50,000 currency units to an account, it will happen and you won't even know how.
Second, the issue with an ACCDE file is that supposedly the compiler isn't going to work because all of the code has already been successfully compiled. I don't think a link remains for the VBA compiler to do anything in the ACCDE file. I.e. you can't pass that text sequence to anything that can do anything useful with it. No way to activate the compiler and that is what you would need to implement this idea as generally as you appear to have in mind.
Third, self-modifying code (which is what you are describing) means you have NO WAY to guarantee code reliability. Someone could enter code with bad syntax and suddenly <BANG><ZOOM> your code crashes because there was no error handling available in that context. They could enter code that violates system security issues in some way and you would have no way to catch it.
Fourth, because user-level security features have LONG been disabled, you don't even have a way to block all sorts of mischief - because there is nothing you can do to block that code from doing bad things. The putative user is already in your system with permission to use this feature. The gate can't be closed but it doesn't matter because at that point, the horses have left the barn.
To say that this approach is incredibly dangerous doesn't quite seem adequate.
@gstylianou - I am not trying to "rain on your parade." I hope to prevent you from going in a dangerous and destructive direction.