The harder option is to contribute to an existing project. This is not an easy question, but I'll try give you a concrete example.
(Disclaimer for others: I'm Nick's coworker, so I know more about him and what he can easily do.)
I contribute to Mercurial. There are two parts of Mercurial that could use some help from a frontend developer. The first is the Mercurial website itself: http://hg-scm.org/
The code for the site is on BitBucket: http://bitbucket.org/segv/hg-website
If you want to improve it, it's as simple as forking, making your changes and sending David a pull request. The site uses Jinja templates, so you shouldn't have much of a problem with them (Nick works with Django every day, for those of you that don't know him. Django templates and Jinja templates are very similar.).
Mercurial also has a built-in web server whose templates need some serious love. The code for those is here (the gitweb, paper, monoblue, etc directories): http://www.selenic.com/repo/hg/file/tip/mercurial/templates
Mercurial's templating language is pretty much a huge clusterfuck for web development. We've been talking about replacing it with something else but it hasn't happened yet.
There are two big, huge, ugly problems with both of these options. The first is that as a frontend developer you need a designer to tell you what to implement, unless you've got some aesthetic sense yourself. I know Nick can design fairly well, so that's not an insurmountable issue.
The other problem is that you'll inevitably encounter people with different design tastes than your own, and your contributions might not ever be accepted because they don't like them! Design-by-committee is a Sarlac pit of good intentions, angry words and ugly results, but unfortunately that's the attitude of many programmers toward the projects they contribute to.
Even though these programmers may have websites that look like they crawled out of 1998, their opinions on frontend and design work hold a lot of sway because they contribute to the guts of the project. I don't think that's a good thing, but I'm trying to be realistic here.
With backend code it's much easier to justify your patches -- who's going to argue when you send a patch and say "this improves performance by 20% according to these benchmarks and passes the entire test suite"? Frontend code (and design) is much more difficult, and the results (rejected patches) can be disheartening.
My advice is to do a few things, in order:
* Talk to the project's community through IRC or mailing lists, and tell them that you'd like to redesign and reimplement the frontend-related stuff in the project. If they're not at all receptive, move on to another project.
* Find a contributor and talk to them. Make a friend. They'll be useful to bounce ideas off of and can help you when you get stuck on something backend-related.
* Find a designer to work with so you can make something beautiful that is hard to reject.
* If at all possible, make your contribution pluggable. For example, instead of modifying one of the theme's in Mercurial's core, create your own theme. That way people can try it out easily before it's merged into core.
* Submit your patches and be prepared to argue for your design against the guy that thinks all websites should span the entire width of your browser window.
Good luck!
I like the idea of possibly redesigning hg-scm.org's public site. Seems like it'd be an easy-in to possibly get into rewriting the built-in Mercurial web server (and build some personal cred in the hg community).