One more thought: This would fail in any subdirectory of the virtualenv (unless it has the same name), or could (by accident) activate an unexpected environment. This could be solved easily, though, by a simple script which checks the parents and prints the name of the env, or nothing (if not below WORKON_HOME).
That's backwards from what I usually do. I use setvirtualenvproject to associate a directory with each virtualenv, and then I just use workon to switch between them and change directories at the same time.
It's quite possible you came to that directory by another mechanism.
E.g., before I was aware of virtualenvwrapper, I defined an environment variable PUTTY_HOME which is used by a script of mine, to change directory depending on this variable (I have several PuTTY sessions which include different colour setups as well). Sadly, it doesn't work to activate the virtualenv in the same step.
I'd prefer workon . to . bin/activate.
(By the way, I always want to change to the new environment when activating it by workon; I dislike the need for an additional command, be it cdvirtualenv or setvirtualenvproject. IMO, the "default project directory" should be the project root. This way, 90% of the folks won't need to bother about setvirtualenvproject ever. I consider this name as difficult to remember.)
I didn't know about the setvirtualenvproject; it's quite usefull. I was just lazy about typing the same directory on workon after cd. Non the less I don't think that workon . would do any harm, but If you are not sure about adding it, it's fine by me.