This is all based on empirical evidence (a boatload of scenario testing I did a year or so back), and tidbits I have put together from the APIs and the dropbox forums.
But Dropbox keeps a big old cache of metadata. While it get into the write-behind cache to S3, and synced to computers in whatever order happens behind the scenes, the metadata cache seems to get updated promptly.
So it isn't possible to inspect the contents of a file right away, in a consistant and guaranteed manor, creating and testing the existence of a locking-file shouldn't be an issue.
* * *
But I also don't want to get too bogged down into the minutiae of Dropbox (though if what I said helped, then I am only too happy). I have great respect for everyone at Omni, especially as engineers.
But as a user I don't really care about the challenges, I care that there is at least some low-friction way to get my data back to my desktop (as well as other iOS devices). And a "perfect" solution isn't required to do that.
A simple import/export feature would do that. Alternatively, since you mentioned writing zip files, then add the ability to open them as a first class file type as well as an OO Bundle (OmniOutliner will explode and recompress as needed behind the scenes).
This latter scenario doesn't require any Dropbox specific trickery, is relatively simple to implement, solves any issues with atomacy, and is unlikely to posses any unwanted side effects. It also opens the door ever so slightly for Windows applications to be able to interact with OO "files". Its a win/win all around.
Few (software) problems are actually impossible. There is always a solution of some sort. More often than not it involves changing the way you look at the problem.