ZFS, SAN’s, HA, Possible

You will not be protected using a raidz vdev + single disk vdevs in the same pool. You should be adding two disks at the time (and mirror them) to your zpool, that will cover one disk failure.

The reason is that copies does not guarantee that the blocks will end up on different disks.

One alternative to expanding your raidz vdev is to use zfs send to store all you data somewhere temporarily while you add a disk and rebuild your raidz vdev and then zfs receive to get it back. It will be hard once you get past a few TB as you need a lot of space to store your data.

First off I'd say you need to take a step back here and learn the difference between block and file storage. I'm not convinced that you truly understand the difference from the phrasing of your question.
You say that you have an iSCSI target machine and mention ZFS. Is your iSCSI target system running Solaris/OpenSolaris/NexentaOS or BSD? If not then you can't realistically use ZFS. (While FUSE might work I would not depend on it for a server)
As to the Windows 2008 cluster systems seeing a ZFS files system on an iSCSI LUN. Not going to happen. Here is where I don't think you understand the difference between block and file storage, I don't know of any decent sites where you can learn about this, maybe someone else reading this can suggest a good site? Here is a link to a halfway decent article about the difference between block and file storage:
http://findarticles.com/p/articles/mi_m0DUJ/is_12_106/ai_n27577413/
I always visualize the storage in layers, in this case you would most likely have:
1) Disks
2) Raid groups (either a ZFS zpool or a traditional RAID group with a couple of disks)
3) Volume (Think C: in Windows or LVM in Linux)
4) Filesystem (NTFS in Windows, ZFS on Solaris, ext3/4 on Linux)
5) Files.
Depending on the iSCSI target implementation the LUNs could be shared up from raw devices (layer #3) or as large files on a filesystem (Layer #5). A ZFS based target would almost certainly use files residing on the ZFS file system. When you export the LUNs from the iSCSI target the underlying ZFS filesystem becomes invisible to the Windows systems using it. To them they just see a blank disk initially. Then you simply format the LUN using NTFS and install clustering. That adds the following layers to our diagram:
5) LUN file on target (Great big binary blob)
6) iSCSI target layer
7) Volume (i.e. D:)
8) Filesystem (NTFS)
9) User data files.
I hope I've been somewhat clear :-)

And to address your central issue of extending LUNs that are NTFS formatted. That's pretty simple, basically use the extend command in diskpart and the volume will instantly expand to fill all available space. I do it all the time on iSCSI LUNs shared up from a NetApp. Be aware though that extending the C: drive can be awkward as you have to reboot into WinPE to take the volume offline for a moment to do the extend. Perhaps this is fixed in Windows 2008 though, I haven't tried it there yet... (Definitely not the case in Windows 2003, it needs diskpart in WinPE)