Firstly just don't use RAID5 please - look around on this site, it's one of the most commonly discussed areas and simply put pro sysadmins don't use R5 unless it's data they couldn't care less about - it's horrid, use R6 or R1/10 - there's no excuse for not doing so.
Then onto your question, create one R6/10 array then carve it into one small boot disk (say 10GB), then into <=2TB disks, leaving any extra at whatever it works out to be.
vSphere v5 can deal with >2TB virtual disks but there's a lot of caveats around that and if you don't need to deal with >2TB virtual disks then I'd avoid the complexity. Don't worry about trying to optimise with such a small system, oh and if you've got StorageDRS just set all disks but the boot one (best to delete any datastore the installer may create on that) into one group and let it manage itself.
It would work, but personally, I wouldn't do that with hardware RAID. There are too many implementations to deserve full trust in unsupported situations. It was not designed for that. It is a hack. Hacks have potential side effects. You won't know what can go wrong until it is too late. But I am sure there are lots of success stories too.
The biggest danger may simply be that the removed disk has an id saved somewhere, and if you add disks in the machine that have the same id, it might do something stupid. (For a software RAID example of this known issue, look at the difference between the ZFS file system's "zpool detach" and "zpool split". Split was created to support the type of thing you are doing. Detach is what you are thinking of doing.)
Do you even know for sure that the second system's RAID controller is compatible with the first one? If not, the disk won't work. (but the chance is high since it is a mirror)
If you used software raid (or hardware supporting 3 way mirrors), you could just add a 3rd disk to the mirror, and as long as you never move the disk back after removing it, you can't get any side effects on the original system. But it is still the wrong way to do it. If you clear out the MBR, superblock, etc. on those old disks and put them in the new system, the RAID controller might see some metadata you missed (unlikely, but who knows for sure?) and try to join it with the array and mess things up. Of course it 'should not', but you never know... this is not a supported situation. RAID was not designed for this, but other things were.
(based on your other question about windows domain servers, I'll assume this one is also about Windows)
On Linux, I would just copy the files (over the network, eSATA, USB, etc.) and reinstall the bootloader. Mac OSX has a tool that does it for you, as a supported feature. Unfortunately, I don't know the best answer on Windows, but you could try the built-in backup and restore feature instead. Or use some other backup software, or use specialized software for copying bootable systems.
Best Answer
Which is better and whether it matters depends on what you want to do with the disk capacity.
If you need to totally isolate the IO between the three virtual disks then having three RAID groups makes sense. If you have IO requirements for individual volumes that will benefit from being able to make use of more peak IO\Bandwidth than can be delivered by 8 disks then you may be better off making one larger RAID group (to get all the spindles into one pack) and splitting that up into the multiple virtual disks.