I realize this is a very old thread, but people do read archived posts for information, so I'm going to add my two cents worth. Adjust for inflation as necessary.
I use this technique of backing up to the nul device quite a lot. I have two databases: Production and Development. Development always starts as an exact copy of Production. I work on stuff there, test application code against it, and frequently trash things. When the data there is either no longer usable, or I simply want to have the latest real data to test against, I run a stored procedure that empties every table in Development, does a real backup of the empty structure, then copies, table by table, everything from Production over to Development. Naturally, this procedure has to be modified as I go, to account for the differences in the new Development version. The last step in the copy procedure is a backup of the newly copied Development data and log to the nul device.
When I am happy with how Development is working, I choose a time when no users are connected (night, weekend, holiday, field work day...), make a full backup of Production, run my data-copy procedure, make a full backup of Development, remove old Production, restore the just-backed-up Development to Production, back it up again and continue using Development with it's new copy of Production data for further development work. This creates a fresh starting point for the Production backup chain, simultaneously live-tests my restore capability, and my normal backup jobs continue uninterrupted. (And yes, I regularly perform full restore tests on other parts of my backup procedures, to be sure that everything is functional.)
During one development cycle, I may run this copy procedure dozens of times. If I allowed everything to accumulate, I would have a massive transaction log, or a huge pile of completely useless backups. Backing up Development to the nul device allows me to renew Development data without littering the disk with junk. The manual full backups when I switch to my new version keep the log chains for real data intact.