Hi Erick,
You have a few different options. You could use the regular sql backup with the copy_only option:
BACKUP DATABASE database_name TO <backup_device> WITH COPY_ONLY
Netapp's official stance will probably be that you shouldn't interfere with the backup sequencing of SMSQL. This makes sense as it is a general guideline to only have 1 dedicated backup process for SQL Server. I have seen quite a few instances where people didn't understand how the backup and transaction log cycles worked and would do other back ups to refresh dev/staging and not realizing they were breaking the restore chain. Clearly enough people needed to do this sort of thing and hence MS finally introduced the copy_only clause.
There is a catch though, that you want to be sure you schedule these out of cycle backups so as to not overlap with SMSQL. You could just disable the transaction log backup jobs in sqlagent until you are done with the native backup(s).
So that is first direct answer to your question, yes it can be done the way you are thinking. However, why don't you leverage the fact that complete copies available in the snapshots that can be mounted and copied anywhere? This will mitigate any sort of complications with someone forgetting the copy_only clause, schedule alignment, not to mention server load.
You could mount the snapshots made by SMSQL as luns on the destination server with snapdrive. Once mounted as driver letters or mount points, you could just attach the mdf/ldf files and use the dbs for a short period. This is really only an option if you are trying to recover some data or need to take a peek at an older version of the db. The problem is that the snapshot will be locked unless of couse you snap clone which eventually will cause an issue for SMSQL. Probably the better path is once the snapshot is mounted, copy the mdf/ldf for the databases to a location in your dev/stage environment.
Let me know if you want any more details.
Rolland