Fault tolerance will be the same, but I think your performance and manageability will suffer compared to doing RAID1 on the host, especially if you have any other VMs using those same disks.
For one, doing software RAID in a guest will use up some of the guest's CPU slice, and if you ever have CPU contention, it's going to kill the disk performance of that guest.
Second, problems with disk contention will be compounded by the fact that your Windows VM will be competing with (presumably) twice as many VMs at the host's logical disk level--one set of VMs for the host's logical disk 1, and another set of VMs for the host's logical disk 2. If one VM goes disk-hungry on either of the disks, your in-guest RAID1 performance is going to suffer. Granted, this can also happen if you RAID at the host level, but it will be more predictable then, and you can more easily figure out which guest to move to another set of disks. Doing RAID inside the guest means manageability will be horrible as you try to balance your other VMs so that they don't kill the performance of that in-guest RAID.
Third, if you're using expanding VMDKs (i.e., not preallocated), you're going to have to deal with different fragmentation patterns on the physical disks. One VMDK might be fragmented across a certain set of physical disk extents, while the other VMDK is fragmented across a different set of physical disk extents, because presumably different VMs' virtual disks span different physical disk extents. Take a simple example, where each letter is the name of a guest, and each letter+number is the start of a physical disk extent used by that VMDK:
A1------B1--------A2B2A3B3
C1-A1-C2-A2-C3-A3---------
Your in-guest mirror's disk performance is going to boil down to the worst of both physical disk layouts. On the flip side, the physical disk access patterns of your in-guest mirror will also impact the performance of the other guests on both disks. If you were to have the disks mirrored at the host level, the disk layout and fragmentation would be the same on both disks all the way down to the device, performance would be more predictable.
If you're unlucky enough to have both CPU contention and disk contention, the guest running your in-guest RAID1 is going to come to a grinding halt--not to mention, all the other guests that are competing for the same CPU slices and disk I/O.
So if you can't pony up for RAID at the host level, I would at least minimize the potential for disk contention by ensuring the physical disks are used solely by the single guest running RAID--in other words, don't let any other guests use those datastores. (You might even want to go so far as to add the RAW disks to the guest instead of using VMDKs.) That way, your only concern is CPU contention, which you should be able to manage more predictably.
Best Answer
You should be able to determine which logical/virtual drives are which.
The VMware client will display your block devices and how they're enumerated. You should know the capacities of your virtual drives. This should be enough to go on.
In addition, if you have your Dell OMSA agents or PERC/MegaRAID .vibs installed (or a custom Dell ISO), the virtual disk information should also be displayed under the hardware tab.
Either way, these things usually show up in order...