As Templeton notes, either processor will easily run virtualized Windows machines using all but the most demanding PC software--and that demanding software is going to be high end gaming (not likely a key application for your real estate PC). RAM is likely the bigger potential constraint with virtual machines, but with 8GB of RAM available you should be able to allocate more than enough RAM to keep Windows programs happy, even if you are running a number of them. If you are only running a single Windows application (often the case--we all have one application we need that only runs there) then you can most often get by even with a relatively small commitment of memory to the Windows virtual machine.
Parallels vs. VMWare Fusion is a matter of taste--there are supporters of each, and while benchmarks are interesting, in practice you aren't likely to notice a difference in performance unless you are, as noted above, running high end games (in which case you probably should, at a minimum, run BootCamp to make your machine a full time Windows machine when used that way or, frankly, just get a machine specifically designed for that).
We have both Parallels and VMWare Fusion machines in our office and, as I noted, we see virtually no difference in performance. We also have Macs dating back a few years (2007 or so) and I don't notice a major performance difference between the oldest ones (with Core 2 Duo processors) and the newest ones (running i5s) with Windows applications, including the Office applications.
There are only a couple of quirks on the "standard" Apple keyboards with Windows virtual machines. First, if you have the wired keyboard with the numeric keypad you may run into quirks when you try and find the "Num Lock" key if you need to toggle the numeric keypad on and off (if you really want the arrows on the number pad rather than using the separate arrow keys). The "Clear' key stands in for the Num Lock key.
The second issue is not really a keyboard issue, per se, but really a difference in the OSs that drives you a bit batty because of the similarity. Both Windows and OSX allow shortcut keystrokes, but Windows uses the Control key while OSX uses the Command key, but the letters that go with the standard shortcuts tend to be the same (Copy is <Control>-C on Windows, <Command>-C on the Mac). Both of the virtualization products attempt to solve this quirk by allowing you to map some (but not all) of the OSX shortcuts to equivalent Windows short-cuts when Windows is running--so <Command>-C will copy to the clipboard.
However, the Command key also "stands in" for the Windows key under Windows--so tapping it normally brings up the Start menu in Windows 7. That can cause the Start menu to appear when you use a "Mac-mapped" keystroke if you release the Command key after you've released the letter key.
If you simply use the Control key in Windows there's no problem--but then you need to remember to swap to Command if you go to an OSX application.
Note that you can hook a non-Apple keyboard to any Apple machine and Windows will see the keystrokes on that keyboard just as it would if hooked to a Lenovo, Dell, etc. piece of hardware running Windows natively. Then you just have to get used to the mappings of that keyboard back to the Mac applications. We have one user running a Microsoft keyboard on her iMac (wanted wireless and a numeric keypad--not an option with Apple with the current products they sell) and it works without a hitch.
On your original question--one other thing I would add about performance. While pricey (you'll pay more and get far less space), solid state drives (SSDs) will give a much bigger performance boost to both operating systems (OSX and Windows) than would additional drives or a higher end processor. My MacBook Air 13" certainly doesn't have the fastest processor and it's maxed out at 4GB of RAM, but with the SSD it's clearly the fastest machine at getting either operating system running and generally faster at most business applications since they tend to be disk, rather than processor, speed dependent.