Changing to a different initiator at a later date would be pretty straightforward, and run something like this:
1/ Put host in Maintaince Mode to evacuate all VMs.
2/ De-config existing software iSCSI initiator.
3/ Power down host and put in hardware initiator.
4/ Configure hardware initiator.
If it happens to be existing hardware in the system I would still perform those steps to keep things clean.
No idea how VMware might present these on their HCL should they support them in the future. What you suggest, 'these devices be listed under "IO devices" and type "iscsi"' sounds logical, however I know for using these devices, both the Broadcom and the QLogic, under Windows is that they split the stack very differently. A QLogic type device is seen very much like a SCSI controller, while a Broadcom type device is very much like a smart network card.
You do raise a far question, why bother the CPU with iSCSI work if the (iSCSI offload) NIC can do it. A question that I can't answer, because I don't know what level of CPU load the iSCSI initiator places on the host, however I would put good beer money on it been relatively small. It would be interesting to see what level of impact iSCSI offload NICs have, maybe there are some whitepapers on this on Windows. However, in my personal opinion and without seeing the data, I think it would be an academic difference.
As for VMware's roadmap, only VMware and those under NDA would know.
