I got blindsided with that question the other day - and it's a doozy. At first, of course, I didn't focus and simply said there's no difference - and that's true for a Unix based organization where your sysadmins work with and for users, but then a few more brain cells clicked in and I said that they used to be different, but shouldn't be any more.
Later I figured out what I meant: IS used to be the customer facing side of a data processing organization while IT used to be the technology or delivery side. In the modern version the CTO picks the hardware and the CIO uses it to deliver service - except, of course, that the real world doesn't work that way and never has.
In the real world organization charts which distinguish technology decisions from service delivery decisions signal organisational disfunction and IT failure - because the right process is to figure out what software the user needs, pick the hardware needed to run it, and then go ahead and do that. Distinguishing IS from IT fractures that process, and enforcing this splitting in the organisational design encourages people to manage via documentation instead of results - i.e. to integrate the "waterfall" development and delivery model into their behaviour by focusing their efforts on never being the one caught without signed-off documentation when someone outside IT/IS finally gets it together enough to call a halt to some project or service.
More subtly, enforcing the IS/IT distinction leads to significant costs and organisational distortions where "his" telecom budget, for example, doesn't touch "my" network budget and "I" can't replace "his" (rented) Toshiba switch phone with an Avaya to add low cost video conferencing while saving the company a bundle on monthly telecom. Similarly it means that the facilities guy pays the CIO's power costs - so what does he care if his Xeon racks need their own private cooling pond? There's a sunk cost fallacy to protect and an organisational structure in place to do it.
Most importantly, however, organizations which perpetuate the old IS/IT distinctions are implicitly saying that breaking the link between software and hardware doesn't matter: i.e. that any hardware will run any software with no relative advantages accruing to any particular combination. That's true in the Windows community now and used to be true in data processing too: nobody in capacity planning agonised over whether to get a Vax or license another couple of megs from IBM - quantities matter, but vendor and architecture are foregone conclusions and therefore irrelevant to the service delivery planning process.
Step outside the cloister, however and software really does determine hardware: you don't run AutoCAD on a T2000 and you don't run LAMP on Xeon - meaning that the halcyon days of single vendor, single architecture simplicity have long since been relegated to the simple minded.
So, bottom line? IT is IS, and organizations that haven't figured that out yet are justing putting in time waiting for someone to use out-sourcing as the least cost, least hassle, way of firing the entire Systems Department.