You still have the risk problem -- the designer might turn in terrible work, or might turn in great work that the customer thinks is terrible -- but I'm guessing that much of the risk is mitigated: image prototyping and UI sketching starts pretty early in the process and features lots of iterations, so you get early warning if something is going wrong; moreover, most web frameworks are designed around the assumption that design elements will change very frequently, because people have learned how much customers love to change the color of the bikeshed at the last minute. Oh, how they have learned.
The scary part of subcontracting is when you subcontract something tricky and coding-intensive, like the entire event-planning module, or the video-sharing module. Then maybe you end up a week away from launch with two weeks of programming left to do. Or maybe your subcon delivers something that looks superficially correct, but which falls over dead during load testing when it sees more than one query at a time, and now you have to rearchitect it under deadline...
It's not that hard, if you read a few books and practice a bit, to be able to cover 80% of design needs (and you can stay in the code these days, ie: work in CSS3 and take screenshots for instance - staying away from Photoshop).
You can also subcontract to a UI designer for the inspirational bits and do the rest of the work yourself.
I suck at UI design (for example making a good looking OK button in photoshop), but I'm a pretty good programmer. How would you approach that? Do you think subcontracting a UI designer would work? Or usually it's the other way around (UI designer subcontract the programmer to build the web site logic).