The project, which lacks a catchy name like other Mozilla projects (like TaskFox, Ubiquity, or Chocolate Factory) is coordinated by long time Mozillian, Benjamin Smedberg; and also integrated by Joe Drew, Jason Duell, Ben Turner, and Boris Zbarsky in the core team.
According to the loose roadmap published, a simple implementation that works with a single tab (not sessions support, no secure connections, either on Linux or Windows, probably not even based on Firefox) should be reached around mid-July. Phase II will deal with the interactions between the two process types (chrome and content), and is aimed for November.
Phase III will take on adapting the APIs for extensibility, accessibility, and performance. By this time (not even guesstimated), we could see a release to play with. Finally, Phase IV will extend the previous development to support several content processes at a time. Security sandbxing will be covered in a later phase.
So it seems we won’t see a multiprocess Firefox for at least a year or so. However, some decisions like taking Chromium’s networking stack to replace Necko, could accelerate the process. As you may know, Chromium is the open source version of Google’s Chrome.
Another consideration is that changes would come at the platform level, so in reality, any Mozilla-based application would be able to create independent processes when web content rendering is required.