As suggested elsewhere, VMWare ESXi is what's available in terms of free-of-charge bare-metal hypervisors, where "bare metal" implies that what you eventually have loaded is less than a full OS.
Xen also has a HVM mode in which hardware-level virtualization is used; in this mode it is able to run Windows guests. Xen clearly has a "bare metal" hypervisor -- as even the Dom0 OS runs under it -- but it is substantially complex to configure and maintain, and places constraints on the kernels you can run under non-HVM domains (of which the Dom0, the primary kernel which passes through hardware access to the others and has administrative rights, is one). HVM requires a CPU and motherboard with hardware virtualization support; see the Xen wiki's list of HVM-compatible motherboards.
That said, you might find KVM more interesting. Rather than using Linux to manage a separate, proprietary hypervisor kernel (as does ESX), KVM builds the hypervisor capabilities into Linux itself. How "bare metal" that is depends on your interpretation -- but if your host running KVM is nothing but a 40MB initrd that has nothing but kvm+libvirt+related toolage in-place (say, something like Red Hat's oVirt), you've got something which in practice is not entirely unlike ESX. The userspace component of KVM is derived from QEMU, which makes it all kinds of powerful and flexible -- something you don't necessarily need for a desktop, but which is very interesting in simulating embedded systems (with, say, only serial I/O and no VGA adapter), setting up complex chains of COW images to backend the storage, or setting up interesting virtual network topologies. Like Xen HVM, KVM requires hardware acceleration. KVM runs undemanding Windows guests (including Vista) reasonably well, but only has paravirtual network drivers for Windows available at this time; other drivers need to use emulated hardware, which is somewhat slower. (Qumranet is funding the development of other drivers for Windows, so expect to see them eventually. Newer versions of the Linux kernel have many other KVM-compatible paravirtual drivers -- for disk I/O, clock, and other devices -- included upstream).
For desktop usage, VirtualBox is a good fit, though it's not amenable to "bare metal" usage at all. On account of its lack of libvirt support, I also consider it unsuitable for QA automation uses. VirtualBox has a paravirt video driver among its "guest utilities" which will provide for automatic window resizing and a sometimes-buggy "seamless mode" where your guest's windows will show up among the host's, making (in theory) for a more integrated experience.
If you're using a "primary OS" that isn't purpose-built for virtualization, you aren't doing "bare metal" virtualization, and a minimalistic, fully "bare metal" solution in which the (micro)kernel in primary control is built strictly for the purpose of virtualization is going to be seriously suboptimal if you want your Windows desktop to display on the same piece of hardware. If what you want is not "bare metal" but hardware-assisted virtualization, everything suggested here offers that -- though for VirtualBox it's a checkbox-selectable configuration option; by default it uses more traditional methods.