The only point of entry for filesystem interactions is the mechanism of system calls, which, in turn, relies heavily (if not exclusively) on VFS.
If someone wanted to create a filesystem that is not relying on VFS, that person would be forced to implement a new set of I/O system calls which would directly interact with the Linux block level.
This is neither elegant nor portable. Besides being a nightmare to implement, debug and maintain, this custom filesystem would be accessible only by applications that use this set of custom system calls. Such approach throws any notion of portability out of the window.
So to answer your question: Yes, it is possible by implementing a new set of system calls, but the only userspace clients of such filesystem would be your own applications. For anything more portable than that, you have to work with VFS.
I saw your earlier question about implementing a high-performance key-value storage system for SSDs which I believe led you to consider this approach. I'd like to add two things:
- VFS is not a bottleneck. It routes the I/O operations to the Linux block level in a very efficient matter.
- The usability of an application that requires kernel patching (with code of questionable quality) is extremely low. Unless you are writing this system explicitly for your own personal use, I would suggest exploring other possibilities before attempting to optimize things within kernel.