The only caveat to this is if you're trying to use SnapMirror as well, which won't replicate 'manual' snapshots.
No, SnapMirror does replicate *all* snapshots from the source file system to the target file system, not just the ones that are driving the SnapMirror process itself.
As you may know, SnapMirror is driven off of a pair of snapshots, and these snapshots would not ordinarily be coordinated with application activity in any way. In other words, these snapshots get created and removed in accordance with your SnapMirror scheduling, not when an application like Oracle is in its hot backup mode, or Microsoft Exchange is "quiesced" etc, etc... As a consequence the self-consistency of the application data within these snapshots is not guaranteed. But....
The snapshots created on the source file system that have been coordinated with an application in some way will get propogated to the target file system by the next SnapMirror cycle that occurs after they are created. They will simply appear as snapshots on the target, with the exact name you gave them on the source. Thus self-consistent copies of application data are normally available on the target for the purposes of disaster recovery (for the applications that need that, such as the databases). See:
http://www.netapp.com/tech_library/3057.html
Kinda. In practice, I would only consent to a clustered pair before running a database on top of it (just as you'd would want redundant paths and controllers in a local raid or jbod).
Fair enough.
However, if you spread your database out across these to take advantage of the added performance as well, then a 'live' snapshot is unreliable, as even with damn precise timing, both filers still won't take them in the same instance of time.
You do have to be somewhat careful for sure, but such a thing is eminently do-able. See:
http://www.netapp.com/tech_library/3046.html
Keith