If only email is available then the users don't seem to engage.
A feedback box within the app feels like a step in the right direction, but doesn't offer any ability to build community.
Uservoice and tenderapp both look like they could work well, and GetSatisfaction seems like a better option once your app is in past the beta stage.
So any help in this area would be greatly appreciated.
There are several separate issues here. If you're talking about testers, that implies that you are running and managing a beta program, in which case the people who are running your beta program are reaching out to your testers regularly, whether by voice, email, survey, forum, or whatever.
If you are talking about a Web 2.0 "beta," in which you're limiting the number of users for technical or business reasons but you aren't actively managing them as testers, then you just have users, and a feedback box is only going to get action from cranks, pedants, and people who really hate or love something about your app. To address this issue you might conduct traditional usability tests in meatspace. Jakob Nielsen and Steve Krug both have good, quick rundowns of how to do this cheaply and effectively. Search for lost our lease usability testing.
Building community is a completely separate issue, and you could consider any number of creative options in addition to the ones you've mentioned, including a twitter stream for your app and a developer blog.
Finally, one of the best things you have going for you is that you have a web app. By writing a simple logging and reporting framework you can gather the actual data about every action your users take on your system, so you can get empirical answers to your questions about what users are doing and how they are doing it.
Things like Uservoice are great for generic suggestions and even finding bugs but they rarely answer your specific questions/concerns because that's not what they're there to do.
I also don't think they're that good at keeping a community together. Seriously. Pushing your users to another site where they have limited interest isn't in my handbook for cultivating communities.
You want:
... to keep users on your site. Pop-in JS things are okay if branded well. But they might still have to log in and then there's the problem of...
... to keep them involved in problems they raise. If somebody raises feedback, raise some back at them. Trap them in the process. Ask them more questions about what they feel is right or why they feel something was wrong in the first place.
... to make giving feedback desirable. One of the reasons SO works so well is its points system. Points mean prizes (or status and power, here) and that's a great way to make people want to keep going at it. Some users will just care and incentives just sweeten the deal but most users won't really care enough without the prospect of benefiting from it some how.
Just to skip back to the point that external services are too generic for directed feedback. As a developer, you sometimes need to ask specific questions to know when something needs changing and this feedback usually needs to be asked at very specific points, usually after a task.
Stick feedback questions on your site at the end of tasks. Eg if a user posts a new something-or-other, at the end of the process, stick an unmissable box in there, asking them how it was for them. You can ask relevant questions and you'll catch more problems because people have just done the task (opposed to them noticing your feedback tab 10 minutes later when they've forgotten half of it).
I think there is nothing like staying in touch with the customers personally (even through emails) and asking them for any problems or usability issues they have encountered. This provides much better feedback insight into the improvement opportunities, than any "Submit your feedback" boxes.