Kevan,
   Buffer Overflows, like almost any exploit, are only as effective as the code allows.  Any exploit is simply a way to interact with a system/app/service/etc in an unexpected way (or in an expected way after which you use the outcome in an unexpected manner).  The code of the target, or the privileges of the target, will dictate your privileges after the attack.  For example, if you use an Apache buffer overflow and the application is running with admin privileges, you are probably going to get su.  If the administrator was diligent enough to restrict its privileges then you'll probably get something less.  If you want to see the gritty details, there are lots of sites that post the code of an exploit.  One of the more popular sites is milw0rm, and this link will take you directly to the code of an lsas exploit that used to be very common:
http://www.milw0rm.org/exploits/293
This should help answer parts 2 and 3 of your question.  Obviously you'll have to be familiar with the code of the exploit (in this case he used C) and the payload.  The payload here is all in hex (the \x(character)(character) that you see), and that hex determines what the exploit will do if it is successful.  You can use hex to directly open a shell, create users, alter files, have a system open a channel back to you, an so on.  There are tutorials for stuff like this all over the net.

On the lighter note, I haven't heard of a central hacker registry (well, outside of the CIA or FBI...) that you can just check to see if your handle is taken.  99% of the time it doesn't matter if you keep it or change it, and many people have several handles for different uses.  The only thing you really need to be careful of is make sure you don't grab the pseudonym of any of the real, no shit l33t guys.  They don't take kindly to that, and flame wars are no where near as much fun as they sound.

Yes, there are some exploit codes written in python, but you would be better off working with hex and C. Maintaining a shell in some environments can be tricky and the more stable your exploit interacts with the OS, the better you off you are.  Oh and please don't rip off my cool handle of Kev, LOL!

I think maybe some clarification is needed.  When writing exploits your major concern is going to be the target and the environment in which it will be used.  The target is generally going to dictate what the code actually does (ie.  the how the hack is done and the payload) while the environment will dictate how it does it.  As an example, the lsas exploit I linked earlier has a bunch of hex that is the actual exploit since it is the data that is sent to the service in such a way that it will cause it to react in the way that you want.  The target (in this case the lsas service) dictates what you can do.  The environment will determine how you do it.  This specific example is coded in C which means it is going to have to be compiled in order to run.  Compiling code is system dependent meaning if it is going to run on a linux box you cannot use code compiled for a windows system.  This comes into play because sometimes you run code on your local system and sometimes you run code on the target system.  If you are running code on your local system you have almost complete control of the coding language you will use so it is more a matter of personal preference.  If you are putting together code that will be executed on a target system then the language you use is controlled by the target environment.  For example, if my target is a windows box I am more likely to write something in C, compile it for a windows box, then move it over and use it on the target.  This is done because I can't expect most windows systems to have built in compilers or scripting support.  If the target system is a *ix box, then I'm more likely to put together my exploit in perl or uncompiled C because most *ix systems will have perl (or python and sometimes ruby) support and gcc (c compiler) support bundled into the kernel.