GRID MOVEMENT
I'm doing something similar, except I have a few different size grids that the player can drag and drop items from (inventory grid vs game grid). When the object passes from one grid to another, I have to adjust the various x,y coordinates.
floor( (coordinate-offset) / scale ) * scale + round( ( scale / 2 ) ) + offset
coordinate - is the X or Y coordinate to snap
scale - the size of a grid square
offset - if your grid doesn't start at (0,0) this would be set to the x or y value at the grids top left spot (you'd use the X offset of you're calculating the X value and the Y offset for Y)
In my particular example, I want to drop items in the center of the grid square, hence adding scale/2.
I plugged all of this into two functions.
fnGetGridCoordinate( x, y ) - takes layout x,y values and returns grid compatible coordinates. This function figures out which grid the point lies on and calls the snap function with the appropriate scale and offset values. Returns grid snapped X and grid snapped Y values.
fnSnapGridCoordinate( layoutCoord, scale, offset ) - takes a single coordinate, scale, and offset to calculate a compatible grid coordinate.
These two combined can give me any arbitrary grid coordinate for any arbitrary scaled number of grids on my screen. The beauty part here, at least from an efficiency perspective, is that all of the redundant checks to see what kind of grid, what kind of scale, etc. are all done centrally, freeing up my object movement code and inventory management to not have to worry about it.
EDIT: I didn't know if it was interesting to anyone else, but since my two different grids have two entirely different scales (the inventory is 30x30 while the game is 40x40), I resize the objects as you drag and drop between them.
When moving from the game grid to the inventory:
Width = round( sprite.Width * inventoryScale / gridScale )
Height = round( sprite.Height * inventoryScale / gridScale )
When moving from the inventory to the game grid:
Width = round( sprite.Width * gridScale /inventoryScale )
Height = round( sprite.Height * gridScale / inventoryScale )
RANDOM GRID CREATION
Since you are using a grid, I assume that you will be using some sort of tile approach to populate your world. I don't know if this helps, but when I thought about doing this myself, I thought of assigning a number to each type of tile you would place (ground, water, path, etc) and then randomly populate a 2d array with values.
This would cover the basics and setting various thresholds of probability would give some structure to it. Your most common tiles that are non-blocking (grass, for example) could have a larger probability of being selected over blocking or other types of special items (like rocks or trees).
If you wanted to have specific complex formations of tiles, like a connected series of road tiles that winds through your map, you could have a second pass go through your world array and overwrite those elements on top of whatever was randomly put there. Your road loop could choose to create a random number of roads at a random length and then randomly build them by walking one tile at a time and randomly choosing the location of the next tile (perhaps limiting it to the four tiles sitting in the cardinal directions).
All of these loops could be enriched with various checks to make sure that the map feels playable (don't add rocks if it will block off a section of the map, stop adding water if you hit the max amount of water on the map). You could even include a further refinement that takes prefabricated complex structures (boss room, special castle) and drops them wholesale into your randomly generated world. This would let you blend in traditional level design elements with randomly generated ones.
At this point, any map element that you can come up with is just a variation on these themes. I'm sure you could get some really dynamic game worlds with this approach. All it would take it some tweaking and tuning of the probability models.