Why redraw every frame when you only need to redraw if a cube is removed or placed? Doesn't make sense.

Do you not know what a game-loop is? This isn't even low-level stuff. Every library I've ever worked with involving gamedev (around three) all require a game loop.

What I gathered from my hours of googling is that I'd only need to redraw the buffer when something in it changes, but something in my head didn't click and I didn't realize I had 40,000 single buffers being drawn for 40,000 different cubes with over 300,000 vertices lol. It makes sense to me now though. I just thought all the drawing could be done at Initialization and I wouldn't have to deal with redrawing until input is recieved

Normally you want to have the render loop running at some rate along with the update loop. In most cases these happen in sync, but they can happen at different rates like for example if the drawing is slow but you want to keep a faster update frequency for physics or whatever. If the scene is truly static, then technically you can just draw it once to the backbuffer and swap and then leave it there, but on at least some hardware it will choke if it doesnt get swaps every so often.

You might also have situations where a scene is static but only rendered as part of the bigger scene on screen... like if you have a monitor showing what's going on in another part of the level. The image on that monitor can be a texture into which you drew that part of the level, but if that doesnt change then you dont have to update the texture... until something does happen.

My map isn't that complicated though. It's pretty static, except for some destroying and building of blocks. I see what you're saying and it makes sense, but for now I just need to get the map drawn on the screen in game time. Physics don't apply here yet

Ok so if I'm going to start simple, I'm going to only draw the sides of the cube that I can see. Can anyone point me to a tutorial on how to do that or give an example?

Why don't you start with this tutorial (it's XNA 3.1) or this website (should work with XNA 4.0).

That's not starting simple. That's a more advanced optimization... which sides of a cube are visible depend on where it is in relation to the camera, and evaluating that for each cube individually isn't going to get you any perf win (unless you have an orthographic projection from a fixed angle...). In your current implementation, your performance is almost certainly CPU-bound, not GPU-bound.

The simplest thing is, like I explained befored, just to put all your cubes in a single vertex buffer at startup and draw that. That will get you interactive frame rates. (Yes, if you need to add/remove cubes at runtime and still have that be fast, then that will be more work... but you said "I'm going to start simple").

The next simplest thing is to use instancing. You have one cube model, and a separate dynamic vertex buffer with instance data in it. There is a tutorial on the XNA site here: http://xbox.create.msdn.com/en-US/education/catalog/sample/mesh_instancing. It will require you write your own shader, because your vertex shader needs to compute the position from the cube vertex base position plus the instance position. This won't be any faster, but it will use less memory, and it will be slightly faster to add/remove cubes.

Thanks. I'd rather start with instancing if I can remove blocks. It wouldn't make sense to draw a big chunk and not be able to change the blocks in it

I think you should do some searching for a good tutorial or book and start from the beginning. Other than that, I don't think anyone here is going to say anything that hasn't already been said.