If there are any licensing issues here, it’s certainly something that’s being tested at the moment - lots of businesses are providing remote working continuity right now by connecting users to their usual desktops over RDP.
There is a licensing cost if they are using a Remote Desktop Gateway or any other aspect of remote desktop services on a Windows server to do it, but my understanding is that using some other VPN product to achieve the same (or guacamole) is all good… What you seem to have stumbled onto is the world of VDI which seems to be prohibitively expensive for anyone but large enterprise, due to a combination of Microsoft and Nvidia licensing costs in addition to the expensive hardware.
The larger licensing issue you might face would be if your current licenses are OEM (ie they came with the PC) you can’t transfer that license onto a virtual machine on a different computer. Pretty sure you can’t use them on a vm on the same computer actually.
I’m about two thirds through a thin client project - motivation is that we had to replace an old 2008 r2 session host for remote access anyway, and with the improvements to RDP in Win 10/2016, we might as well set up some thin clients to replace some of our more ancient desktops, as the experience should be considerably better.
The main point to make is that if you are planning that your thin clients run linux, the FreeRDP/Remmina client is much worse than the Microsoft client (on WIndows), because it doesn’t use any hardware acceleration.
Just for context on this, the modern RDP protocol uses an AVC 444 video stream to encode the entire screen - the encoding of this is hardware accelerated if such an encoder is available, so our Windows Session host has a Quadro P2200 assigned so that we can use the NVEnc chip for this part instead of chewing up our CPU - the average desktop can use intel quicksync for this purpose (this is another headache of your thin client proposal - you’ll struggle to avoid software encoding with several win 10 VMs).
Anyway, I hoped that a Raspberry pi 4 (or even 3 for that matter) with it’s robust hardware decode capabilities would be a perfect thin client for this job… but freerdp can’t use it, so as soon as your user tries to watch a youtube video full screen they’re watching a slide show.
Similar hardware can be used if you are willing to use the Microsoft Remote Desktop Client for Android - this does use video acceleration, so on something like a Fire TV 4k stick, or half decent android TV box, the experience is fairly good… but I found some keyboard shortcuts (like alt-tab) weren’t passed through, and if your monitor doesn’t run a standard tv resolution (ie 1920x1080) then it’s another headache getting the android device to run at that resolution.
So ultimately, I’ve bought a few Windows nettops to solve our problem - they are licensed to run Windows 10 pro so I’m going to thin it down and script them to behave as thin clients (https://gshaw0.wordpress.com/2017/06/11/build-your-own-thin-ish-client-with-windows-10-ltsb/ has someone detailing a similar project).
Of course, you might not care that your users can’t watch video/get graphic rich experiences, but it’s something to be aware of going in - your users will get a worse experience from this unless you plan and test carefully.
With all that said, I have to say your motivations for the project seem misplaced.
You protect the data integrity and availability of your files by storing them on a server (potentially with ZFS) and making sure you have regular backups.
If important work is being stored on the desktops (or as a safeguard against desktop data loss/downtime) you can run something like Veeam Agent (which is free and good) on the desktop to take regular backups, if the drive breaks you use the restore media and get the computer back within an hour - if the hardware is standardized you can just keep a spare desktop for this purpose if uptime is that important.
You need backups anyway, using Veeam is a much better solution for the issue you are talking about than coming up with your own mini-VDI infrastructure.