MIG has several options and can be very annoying to use. here is the basics:
1.) the core developers assume you use IOB's for everything for some reason, so the coregen will ask for valid locations for things like ref_clk and sys_clk and "error", even though these might not be in the end design. Really, the example isn't very good for this reason.
2.) there are a lot of UCF constraints that are important. again, they write them for the example, so you'll need to modify them slightly (usually by adding * to the start of each INST/NET constraint that is wrong.)
3.) SDP is nice because you can do reads and writes independently. However, DDR3 will favor block block accesses -- writes of 1-4kB and reads of 1-4kB. This is because there can be a large turn-around if the read address and write address are done on multiple rows within the same bank. With larger block transfers, the overhead is reduced. if you are only using DDR3 for the size, and not for the bandwidth, you should be ok with random accesses.
4.) If you do have lots of random accesses, you may benefit from some form of caching system.
5.) I'm not sure EDK's MIG gives you access to the entire RAM. IIRC, they only support 32b of the 64b interface for microblaze. It's possible the native interface would work, but I'm not sure there's any advatage over just using MIG at that point.
the 3rd week of June isn't that far away. I'd definatly look for someone where you work who has gotten this to work before.