Or if you want to work on something that is yours, let's reimplement stuff you've done, but let's not take a whole day where I work and I don't get paid. Or ask me to build you features that go live, and I won't get paid and might not get the job...
There are better ways to achieve what the prospective employer is after, without getting me to spend 8 hours building features for your application with a risk that I will get nothing out of it, but you might.
If that makes sense?
It seems at least as likely you'll learn something material as I'd get working code out of you that the lead dev couldn't have written on his own given his better understanding of the problem domain.
I would say that if getting the opportunity to evaluate the company as a fit more substantially than a traditional interview isn't adequate compensation for the company getting to do the same for you, that's quite possibly a good sign to you and the company that you aren't really a good fit.
That isn't any logical grounds to assume I wouldn't be a good fit. That just means the ROI tells me it's not worth my time. Without seeing significant potential reward and a reasonable possibility of getting the job, and actually wanting it, there is no way I'd go in for more than a couple hours of coding without compensation.
You say that the ROI doesn't work for you, but the chances are those odds mean it doesn't work for the company either (we could invest the time and money in the interview and still not land you - that's always a possibility but here it sounds pretty likely).
In all honesty it sounds like the right thing in these situations isn't to pay money, it's to either find a more efficient way to work out whether it's a good match (so that a long interview was either unnecessary or something the candidate was willing to do) or for both parties to walk away and look for a better way to spend their time.
Just to be clear, it's not that I don't value the developers time, I absolutely do, it's just that I think handing over money in this situation (a) may work for the developer but doesn't for the company and (b) rather muddies the water.
"The applicant's concern is "will I really find a good fit in this company and advance my career here?""
Is a big deal too.
Wondering what the company is really like? You're going to get to work for a day with one of their devs, see what they're like, see their code base, their tools and processes, their standards.
Given that most companies oversell themselves (the old saying interview is like a seduction, a job is like a marriage), this would seem to me to be an amazing opportunity to find out if this is the right move.
Sure you want to be pretty certain before you commit this time, but so will the company - unless you're off the charts great it's likely they'll lose as much of their lead dev's time as he gets you up to speed as they'll gain from you - so as a final stage in a recruitment process that could lead to a long term commitment, it seems win win.