Here is the t/ directory for one of my modules. Not everything in there is perfect (e.g. I should probably split 10_basic.t into multiple files someday), but it works. A few things to note:

• The tests are numbered so they'll always be run in the same order.
• I didn't split the author tests into a separate directory, but I do like Corion's idea to do so.
• I've tried to make the test directory fairly self-contained, for example Config_Perl_Testlib.pm and perlcriticrc are also located in the t/ directory. The tests are hardcoded to this structure for now ("use FindBin (); use lib $FindBin::Bin; use Config_Perl_Testlib;"). While not extremely elegant, again, it works, although it may not be advisable for large projects where the t/ directory might get too cluttered.
• In 00_smoke.t, note how I use Test::More's BAIL_OUT function to abort the test suite if some basic things go wrong.

How should I group my tests into the different .t files?

You actually have a lot of flexibility - the very basics are that prove and similar tools run the t/*.t files and expect Test Anything Protocol output, the only other thing to keep in mind is to set @INC appropriately, e.g. via prove -l. You can start with a single .t file, and as it grows, start splitting it up into multiple files. How you split it is up to you, but consider that while working on a specific part of the module, you may want to run only the tests for that part of the module. You can see by the various responses you've already got that this is a TIMTOWTDI issue :-)

How are the pros running individual test files quickly and efficiently with vim?

I run all my Perl from the command line, in the case of tests usually prove -l, as it gives me the closest environment to how my scripts will be executed later. Some IDEs do things with @INC, the working directory, or redirecting STDIN/OUT/ERR that I sometimes don't agree with, so I've found it easiest to simply have a terminal window open.