If I can't see your code, I can't tell if you're just bullshitting really well or actually pretty cool. And no, forking a bunch of other people's repos doesn't count--I will check your commit history.
Most tech employers own everything you do, even on your free time. So a large GitHub history can send the message that you're not employed all that much.
I don't think it is fair to expect you to talk about your old company's codebase in an interview--I'd love to have that conversation, but I understand if you wouldn't feel comfortable doing so.
So, I can ask you questions in person, and get some response. Maybe you interview well, and you can answer things easily; maybe because you know your shit, maybe because you crammed with "Crack the Coding Interview"-like books, maybe because you have inside information on what'll come up in the interview.
Maybe you interview poorly, and if I ask you to whiteboard something you have a panic attack even though you know it cold. Maybe you are having an off day, or our conversation just flows the wrong way and you don't communicate to me the experience I'm looking for that you already have.
By contrast, if I have your github (or sourceforge, or bitbucket, or whatever), I can infer certain things about you: I know what languages you write in, I know whether you roll things from scratch or make little changes to other people's projects, I know how much you care about code quality and commits, I know what sorts of projects you like to work on in your free time.
In an interview, I can (and will!) ask you about some code that you've written, both good and bad, and I can see how you respond--are you defensive, apologetic, humble, humorous? I can ask questions about specific projects, work through your thought process, and get a much better feel for how you are on a team.
As to your question "What is the difference between experience writing proprietary code and experience writing code that happens to be published on GitHub?"
The difference is that I know for certain you can use git, I know that you aren't hiding behind your team on that project, and I know what lines of code you did and did not write (barring certain corner cases). Proprietary code is also usually pretty fucking dull, honestly: you're usually patching or hacking in some business logic for a legacy app that isn't that great to begin with. If I cared about that, I'd just hire some legions of code monkeys from India and be done with my problem.
I'm curious as to what your thoughts are on the difference between these two things. Rolling from scratch seems like more work, but sometimes gathering enough knowledge and understanding about someone else's project to be able to make a change to it is even more work.
If you have little commits that just change some config settings in your fork of a common jQuery library, that's not a big deal.
If you have little commits that change some deep magic in sizzler, okay, that's something we should talk about.
If you rewrite a software rasterizer, just for funsies, that's something to talk about.
If you write yet another web framework in Ruby, or lightbox plugin for jQuery, I'm going to call you out on wasting time.
If you can explain why your implementation of half of the functionality of Rails is desirable, and satisfy me that you're doing it for engineering/business/safety reasons, I'll be really impressed. If you admit it was for the lulz or to learn or because you didn't know any better, I'll admire you for your honesty. If you did it because async is srs bsns guise also activerecord more liek activerecrud amirite, I probably will let somebody else have the joy of breaking in a cowboy coder.
It can be very, very hard to commit work to other people's projects--I skipped even the modest task of putting out a Visual Studios make system for somebody's Minecraft clone, for example, because I just didn't want to have the "Cmake? Fuck cmake!" argument.