I would probably reserve pushing out a gem fork if you really really need to. One of the Gemcutter contributors David Dollar puts it very eloquently:
I think the general idea is that gem forks should be a huge special case. I’m somewhat of the mind personally that making gem forks too ‘easy’ causes a great deal of unnecessary fragmentation in the community. It seems reasonable to me, that if your project is going to depend on a gem fork, that the dependency resolution not be automatic, and your installation instructions can tell the user how to get the forked dependency.
If a fork is going to be long-term, or a true alternative, it should probably be reregistered under a new name as a different project.
I think the more elegant solution until you plan to maintain it for now is to just keep it on GitHub, if you absolutely need to push the gem.
Nick, thanks so much for your reply. GemBundler seems super, super cool. I was envisioning moving over a lot of my support tasks with RoRPortable and use the underlying Ruby interpreter to get things done quickly on computers I support and also work on Ruby/RoR when I feel like it without worrying about moving to different environments. I am not sure if I can GemBundler to work with it (since RoRP needs a good deal of work, but I am treating all of it as a learning experience). Nonetheless, I think you did a great job answering my question: this closes the gap in my understanding how to work with gems in the context of personal forks and the new GitHub way. As someone who has relied on CPAN and various Linux distros, I totally sympathize with the need to enforce strong organization of package namespaces and avoid the confusion over which package is the "real" or "stable" one.