SO what did I do wrong that I don't have a bootloader?
You had also mentioned earlier that getting the SD card to work is doable, but a chore. How do I enable it? or would it be better to get a LCD panel that has the card and use that, like the Viki, or any other recommendations?
"Bootloader" is a tad misleading in the context of AVR microcontrollers.
For making this discussion easier - lets use the terms 'sketch' to mean 'arduino platform based source code' and the word 'Bootloader' to mean "the thingy that detects when I want to load a sketch and lets me upload it" . And for purists - no these are not the correct memory addresses etc - this is written to explain the concept not for technical application itself 
Now, when an AVR turns on, it reads its memory and starts running whatever code is in memory and starts at address 0.
The 'Bootloader' is actually just a special kind of 'sketch'... Its the guts of whats needed to 'bootstrap' the AVR to the barest minimum to get some sort of comms working, usually serial but nowdays increasingly USB handlers. After its done that, it usually has some sort of 'trigger condition', and once thats been met or expired (such as timeout based ones on the arduino bootloader) its told to go and load the 'sketch' (or 'rest of the code fragments') from a certain address onwards - lets call it "2048" for conversational purposes.
The 'bootloader' if it receives the trigger its setup for (jumpers on pins, hello commands from avrdude, etc) then it will switch to listening on whatever comms port, and receive the downloaded file (it doesn't care what, hence why you can 'load the wrong firmware') and sticks it in from location 2048 onwards. This is what happens when you upload via Arduino IDE using the 'arduino bootloader' - your 'sketch' is received by the 'bootloader' (which is really just another sketch at address 0) and the bootloader puts it in from 2048 onwards.
When you reset the board, the bootloader, living at address 0, runs. The code waits for the trigger, and this time, not being met (no upload inside 2 seconds, no jumper, etc) it just goes straight on to load whatever lives at 2048 onwards.
Now - If you upload using an ICSP programmer (usbtiny etc), it doesn't pay any attention to this. It instead uses the raw 'shutup and take my file' commands to the AVR and whatever it transmits starts living at address 0 onwards. This is how one gets around the 'chicken and the egg' problem of loading a bootloader without a 'bootloader'. This is why the 'Burn Bootloader' options under Arduino IDE need you to also setup a 'programmer' and can't use the built in bootloader... since that bootloader on the board no matter how much you ask it to will always load the received file to address 2048 - Useless for a 'bootloader'.
The same happens if you use avrdude and a programmer, or arduino ide and the 'upload using programmer' option. The uploaded file lives at address 0 - so it gets run every time and there simply is no 'bootloader' to accept further programs. One must use either programmer again, or load a 'sketch' that does the appropriate bootloader things one wants so that it lives at address 0.
So how do they get the bootloader and the default 'sketch' onto the AVR before it ships, or back at the arduino factory how do they load it so that it has bootloader+blink running ?
What they do is - Load the bootloader to one AVR, and then using the 'bootloader method' (so serial via arduino ide, usb for hidbootloader, etc) load the sketch they want onto the AVR. It now behaves how one would want - loads bootloader, checks trigger states, then runs blink/marlin/whatever. They then use the ICSP to 'read back' the entire loaded memory on the AVR. This gives them a brand new .hex file that now contains the bootloader at address 0 AND the 'running sketch' at address 2048 onwards... and when they load this to other AVR's they also now have the 'bootloader' and 'sketch' running - which is as this all explains really just one long piece of firmware loaded from address 0 onwards 
So thats why, once you upload using a programmer directly, you 'kill off' the bootloader. To restore it now - simply follow the instructions at the page I already linked above at lincomatics blog - he covers how to load either of the 3 bootloaders.
Why your bootloader didn't work originally - It probably did, just wrong method used. Can't tell you what, as I dont have a generic geeetech board, and there really is about 5 different ways you can program them, so when you don't know for sure, it really is a matter of trial and error. Often just bypassing it and loading a known good bootloader using an ICSP programmer is definately far easier!
There you go - hope that shed some light on the whole subject and didn't just confuse it more
Re the SD card - personally I'd just do it in combo with an LCD... its pretty useless without an LCD anyway. But if you read the latest beta firmware thread over in software/firmware, it covers it all in gritty detail.
]]>
. The board is no longer showing up in the device manager, even though I can hear it (Windows recognizes it) when I plug it in, the device manager "blinks" but there's no new device anywhere (USB, COM ports, HID devices, etc...).