Boot up a virtual machine natively

By raping the battery do you mean getting almost 3 hours of Windows? In practical terms there isn't that much difference between running Windows and Mac on current gen MBP. I have been doing this for over a year with zero issues whatsoever. There is enough battery life to last an hour long commute twice with a few minutes of use in between. Put it this way, I went from from using Windows full time on the machine to using MacOS full time and didn't see any practical difference in usage.

What you want to do is install Windows using Bootcamp assistant, do not screw around with the partitions and install VMWare Fusion to use bootcamp partition. You can then have a choice of running Windows natively or running MacOs and being able to fire up the windows install in a VM if you need to do something quick in that. This makes your laptop very versatile indeed.

This part is key:

run the same Windows 8 install in a VM

Yes, there are some serious caveats that would make this extremely difficult and possibly unstable. Virtual machine monitors (VMMs) like VirtualBox, VMware Workstation/Player, Virtual PC, etc. typically present different virtualized hardware than what your actual system has.

QEMU-based VMMs typically present a PIIX3 chipset to the guest OS. VirtualBox offers an option for PIIX3, ICH9. VMware Workstation and VMware Player also emulate a chipset, which your PC probably doesn't have.

In previous versions of Windows, there was a feature to select Hardware Profiles, which might allow you to pull this off safely, but that's probably not the intended use for it. There isn't really a good way to choose the profile automatically, either.

Other features which would drastically differ between your real hardware and the virtualized hardware include: video adapter (any accelerated graphics will need a paravirtualized driver, and that will likely fail), disk controller (you might be able to pull this one off if you have the real hardware for it, like the LSI 1068e, a real BusLogic card, or, most likely, you can set your disk controller to present the AHCI SATA interface and convince your VMM to present a bootable AHCI disk controller), USB (if you have an Intel board, you probably have a UHCI USB 1.x controller instead of the OHCI that VirtualBox presents), audio (SoundBlaster 16 and Ensoniq Audio PCI are commonly emulated, but outdated hardware), etc.

Doing this on Linux isn't so bad, as most of the hardware configuration details that are presented to the OS are chosen at boot-up time, with the exception of things like udev rules, so you may get weird network interface names.

The real danger, I think, lies in having the VMM's paravirtualized drivers which perform hypercalls by doing things that are undefined on a real platform. If the paravirtualized drivers blindly assume that the VMM is present without checking, it will very likely cause your kernel to trigger an unexpected fault, which translates to a kernel panic on Linux and a BSoD on Windows (if you don't trigger the triple-fault shutdown first). How likely is this? I've actually had trouble with this on Linux with the PV VMware display drivers triggering a hang on Virtual PC.