A microkernel only gives you scheduling, IPC and virtual memory. You and others get to implement everything else on top of that. That means there are no NUSE or FUSE interfaces and if you want them, you get to implement them as part of userland servers. There is no kernel in between to say “this is how it is done”. How it is done is a consensus among the userland components with the kernel abandoning any role for telling them how to things beyond providing the IPC used to communicate.

With NUSE and FUSE, the kernel is very much going in between userland processes and saying “do things this way”. Microkernels do not have a monopoly on the idea of moving code into userspace. There are terms for other designs that push things into userspace, such as the exokernel, which goes well beyond the microkernel by handling only protection and multiplexing.

I think the term library OS has been proposed for what FUSE/NUSE do. It is a style of doing things that turns what were kernel functions into libraries that can either be accessed the old way through system calls redirected to daemons via shims or as libraries in the process address space. This is an extension of monolithic/hybrid kernels, rather than a microkernel. Closely related would be the anykernel concept as demonstrated through rump kernels, which supports the same code being compiled for both in kernel and in userspace uses:

https://en.wikipedia.org/wiki/Rump_kernel

Earlier work in this area can be found in OpenSolaris, where various kernel code were compiled both as userspace libraries and kernel modules. The most famous example is ZFS (it was/is used to make development faster via stochastic testing), but other things like the kernel encryption module received the same treatment.