The key to dropbox's awesomeness is delta compression, which this is totally going to destroy. Aside from placing a greater load on their servers in terms of storage and bandwidth, it will degrade your experience. Caveat emptor.
Not necessarily. It looks like encfs is vulnerable to a cleaning lady attack, in which case dropbox (acting as cleaning lady) will be able to recognize and take advantage of unmodified blocks.
That said, this approach won't be able to recognize blocks which are duplicated (rather than merely unmodified) either within a file or between two different files (actually, I'm not sure if dropbox can recognize data duplicated between different files, even without encryption; but tarsnap can), and sensible generally want their encrypted filesystems to be secure -- so this really isn't a very good solution.
The real issue is conflict handling. When Dropbox detects a conflict between two versions which have become out of sync in a non-fast-forward type way, it creates two versions, the more recent version, and the old version with the host that created it and the date.
This is probably the right thing to do, but since it is doing so for the encrypted versions of the files, rather than the unencrypted versions, you end up with files like: "./j85-6kOFk3Gg0Lg1TiuqgqIz/8p2kJa8tboYSSpadfuiE9Tuq" and "./j85-6kOFk3Gg0Lg1TiuqgqIz/8p2kJa8tboYSSpadfuiE9Tuq (quiet's conflicted copy 2009-10-21)" with seemingly no way to access the conflict version through encfs.
If anyone has an idea how to fix this, I'd quite appreciate it. Otherwise, I'd really caution anyone from using encfs as a solution to encryption on Dropbox!
(TrueCrypt is a terrible solution for this as described in the posts below, due to needing to sync the whole volume every time.)
I don't know whether this attests to Dropbox's amazing delta compression, or implicates TrueCrypt's encryption.