ZFS is not a clustered file system, so what you talk about wouldn't actually work as described. In order to increase the capacity of a server's storage, you'd need to add more disks to the host, either in the chassis, or, if that's full, in a storage array. A host running ZFS can have up to 2^64 zpools, and each zpool can contain up to 2^64 vdevs, so you are highly unlikely, this side of doomsday, to reach that limit!
If that's not an option, and you want to integrate a new host into your infrastructure, you can export your ZFS file systems using NFS, and then mount them so that each host has the same view of the network. This way, no matter which storage box you hit, you'll get the right stuff back.
This is not clustering, and does have some overhead in terms of network traffic (although that can be somewhat mitigated by using automount to save protocol chatter from cluttering the network on quiescent file systems). However, with the guarantees that ZFS makes about data integrity, and the redundancy provided by RAIDZ, I think it's a great way to go about setting up a high capacity storage system, and is in fact how we do it at work, where we have dozens of machines exporting hundreds of TB of storage. A user can log in to any machine, and can use the same path to get to their data, giving the impression of a clustered storage setup. Exporting datasets with SAMBA means that Windows users can gain access to the data, as well.