For most job offers I've gotten I've asked to review the source code post-offer. I've even done this in a couple interviews -- can't recall ever being denied.
In one particular instance I came back to review the code for a product that required a level 3 security clearance; the hiring manager happily complied, letting me spend over 2 hours alone studying the code on a workstation in a side office. One reason I passed on that position was due to the code being more spaghetti than I would have preferred.
I like your idea. I would also like to add one I learnt through experience.
I usually meet with the team on a casual event outside the office before accepting any offer. I find that its a very good way to find out about the team dynamics. A lot of warning signs about management can be easily spotted within half an hour of talking to them.
Inside of an interview, what usually happens is we get into a discussion of the architecture of the product I'd be working on. Then I pepper questions about the codebase itself, and after a few questions I'll say "Wow, that sounds interesting. Mind if I take a look?"
Post interview I'll talk to the hiring manager and express how much I enjoyed meeting with the team and love the product, then ask if it would be alright to stop by to take a closer look at the codebase, watch how the team works in action, just be a fly on the wall.
I would love to do that as well. But its taken me a while to understand our current system, and the code itself isn't bad, its just some really poor high level design decisions that have led to a lot more of it than is needed. 2 hours in it still looked decent to me.
In one particular instance I came back to review the code for a product that required a level 3 security clearance; the hiring manager happily complied, letting me spend over 2 hours alone studying the code on a workstation in a side office. One reason I passed on that position was due to the code being more spaghetti than I would have preferred.