My recommendation would be to load the map as tiles with tiled map editor and add support for reading-in objects, not just tiles, from those xml files, so you can use the objects to define the collision points. Here's an example of what I mean:

The red rectangles are objects drawn in a defined "collision" layer. Blue rectangles are objects drawn in a defined "exits" layer. And you can see an icon of a sword there, which is actually a tile-object, not a tile, and represents in game logic (in this case, a mob). There are a few advantages of this approach:
Lets you rapidly prototype a new level. All the collisions, mapping, mobs, etc. are in the same place.
Since you're using tiles, you can draw a different map easily. I.e., you don't have to take an image into a photo editor, you can just draw new walls etc., and play around with it.
Separating out the game logic from the level editor lets you have someone with no (or little) knowledge of the codebase easily create maps.
By using objects for the collisions instead of the tiles themselves, you have more versatility. I.e., you can draw polygons that aren't square for, for example, diagonal collisions. Or you can draw lines so that an un-enterable "block" needn't be a full tile wide or tall.
As noted by the astute Benjamin "Danger" Johnson in the comments below, using a tile map does have its disadvantages, including increased load times and rendering performance. In your question you mentioned your goal was for prototyping, so my general advice is not to worry about load times and performance until you're ready to worry about load times and performance. If you develop your maps with a tiled-approach, you may decide when you're ready to optimize that it's worth migrating some or all of them from a tile approach to larger images.