The next step involves making use of Gentoo's Portage package system to assemble the rest of the pieces and bring the system up to date. Because Gentoo revolves around source code as closely as possible, Portage doesn't grab precompiled packages from a repository -- it downloads the most recent source code for a given package, compiles it "on demand" for the platform you're running on, and then adds it to your system. Because compiling can be slow, especially if you're compiling a whole system's complement of A-list programs, some major applications (Firefox, for instance) are available in a precompiled package.
At this stage you also have the option of tweaking how Portage compiles packages, such as what optimizations are applied, although you'll generally want to keep this minimal the first time out. A similar amount of tweaking can be applied to building the kernel itself, so that features like multiprocessor/multicore or PC Card support can be enabled or disabled. Again, be warned that trying to tweak everything the first time out may only make things worse -- save it for when you've run through this whole process at least once with as close to a stock configuration as you're planning to use.
Once you've created the system proper, one of the other key elements you may work with to further shape Gentoo is USE flags. These flags, set in an environment variable, are used in conjunction with building packages -- they let you include or exclude support for specific features from various packages as a way to streamline or expand your Gentoo build. For instance, if you're creating a system that doesn't need support for X11 (like a headless server that you're only administering from a command line), you can use the -X flag to negate compiling in support for X11.
To create a system that you will actually be distributing to others, you need to get some experience with a Gentoo tool named Catalyst, which is designed specifically for building components of a released Linux distribution. The stage3 tarball you installed by hand earlier is one of the things you build with Catalyst. It's also possible to build a live CD using Catalyst as one of the tools to accomplish that (or build one from scratch without Catalyst, which allegedly has slightly more flexibility).
Share And Share Alike
So what's the next step after creating a distribution of your very own? Aside from "eating your own dog food," as described above, you might want to share the love: release it to the public.
It's an optional step, but a hugely useful one, and you may realize that the microdistribution you cobbled together has an audience after all. If your audience is thoughtful, you'll get valuable feedback on what works and what doesn't. And even if you have no intention of releasing the distribution broadly, you may learn things that help you improve what you're trying to do.
There's a few ways to get a distribution out there. One of the most common is to submit mention of it to DistroWatch, probably the single most well-trafficked site that deals with the panopoly of Linux distributions out there. As I write this, its submissions form is offline pending some reworking, but DistroWatch can be contracted via e-mail; also note that it doesn't accept submissions for certain types of distributions at all (such as those hosted within Windows).
Actual hosting space for a distribution is another story. SourceForge generally doesn't accept hosting for Linux distributions due to the size involved, although it can be used to host the bug-tracking or discussion lists for such a project as long as the data itself is kept somewhere else. Fortunately, Web space has become amazingly cheap as of late, although to make the distribution a little less onerous you may want to use BitTorrent as a way to offset the bandwidth burden.
Remember to distribute the source tree as well. I'm assuming for the sake of argument that the distribution you'll be creating, and its component packages, are GPLed, so remember to also distribute the source code. The source doesn't have to be provided in the same package as the binaries, especially since the source tree can be quite large; several gigabytes isn't unheard of. What matters is that you make it available and document that fact, especially if you end up making any changes to the source.
Finally, speaking of documentation, that's something else you may want to provide with your new distribution. Whether it's just a simple set of README pages or a full wiki, you'll want to take the time to talk about what's special about your distro -- quirks you've noticed, things to try (or not try!), and ideas for where you're going with it in future builds. A distribution is, after all, always a work in progress.