User-mode drivers "plug into" a kernel interface for interacting with hardware, so in theory they can do approximately anything that a kernel-mode driver can do, aside from things that the driver framework doesn't support. For example, if the hardware maps its I/O to specific physical memory addresses, the kernel can map those addresses to the user-mode process; true DMA is not available from user-mode, but a user-mode driver can request that the kernel map arbitrary memory ranges into its address space.
User-mode drivers also usually run with very high privileges, including the ability to install kernel-mode drivers if so desired. The point of user-mode drivers is to make them easier to develop and debug, and less likely to trigger a kernel panic if they fail (though note that e.g. two WDDM user-mode video driver crashes in rapid succession will still cause a panic, or would last time I tested extremely beta NVidia drivers). It is not a matter of protecting the machine, either its data or its hardware, from malicious code. Don't load untrustworthy drivers, kernel or otherwise!
Are the user mode drivers restricted to the device they are inteded for?
As far as I know, there's nothing stopping a driver from being loaded for the wrong device in a category, and I'm not sure if it's even limited by category. It's possible from the built-in Device Manager to load entirely the wrong driver for any device (you have to click a lot of buttons that almost nobody has needed in the past decade or two, and you'll get a warning that Windows can't be sure the driver will work, but it won't actually stop you from trying). Given the privileges of user-mode drivers, they could call the same APIs as Device Manager. Alternatively, drivers (at least, in the kernel, and I believe user-mode too) are polled for compatibility with new hardware (this is how plug-and-play works) and a malicious one could just announce itself as working for every device.
With that said, it's worth noting that lots of hardware has its own protections against various failures. Thermal shutoffs, firmware signature checks, bounds-checkers on commands that translate to physical actions or voltage/current levels, and so on all make it much harder to destroy hardware with malicious software than it used to be. That's not to say it's impossible, especially if things like "halfway-flash the firmware and then leave the device in an inoperable state" count (though modern motherboards, at least, often have a backup copy of the old firmware).
