5 seconds for a 1.7 GB working set sounds really low: it would mean you could write > 200 Mb / sec assuming you could get data from mongodb infinitely fast. Also, what happens to your mongo database while you export data (can you still write to it ?).
In any case, mysqldump is rarely the bottleneck - restoring is. For the latter, you really want to use mysql from percona, because their version of mysqldump has an option to void the data without index first, and create the index later (--innodb-optimize-keys=True). The effect will depend on the database schema of course, but I often see one order of magnitude difference for simple, large tables with a few simple indexes.
5 seconds does seem very fast, but this is on a high-end Rackspace server with what I'm sure are very fast hard drives and some 64GB of RAM. It's a bit slower on "normal" boxes, but still quite quick.
You can still write to your database, yes. There's a flag, --oplog, which when passed to mongodump, will record the oplog position at the time the backup starts, then dump any ops since the backup started as a part of the backup, so they get replayed on restore. This leaves your data consistent with the database state at the end of the backup without the need to issue a write lock.
In any case, mysqldump is rarely the bottleneck - restoring is. For the latter, you really want to use mysql from percona, because their version of mysqldump has an option to void the data without index first, and create the index later (--innodb-optimize-keys=True). The effect will depend on the database schema of course, but I often see one order of magnitude difference for simple, large tables with a few simple indexes.