My organization accounts for QA/QC with the definition of "done"; QA is not a second class citizen of the organization, but rather a crucial part of the development team/process - and the story is not DONE until QA says it is. Therefore it rolls over across iteration boundaries as needed, and is only demo'ed when it is done.
The problem we have had with Agile thus far seems to be our inability to produce accurate estimates without doing Big Design Up Front which ultimately means spiking every story before we can get started. Nearly every time we try to shoot from the hip on story estimation for anything moderately complex (or worse), we have missed by several multiples the actual amount of work needed.
This is mainly due to the product being very complex (think enterprise scale SaaS, tens of millions of users, terabytes of data, complex data modeling, and numerous technologies being adapted with a variety of API/interfacing solutions) with many interconnected systems across multiple data centers and cloud services... you just can't stare at a story in the backlog and come up with a meaningful estimate off the top of your head no matter how well defined the acceptance criteria are because no one person knows what the potential impact is to all those systems.
But we're committed to working on improving our processes, cross-training, and reduction of overall system complexity to eventually be able to do just that and are sticking with Agile because it has forced us to take smaller bites which has really been a challenge for our sales/marketing and product owner teams because they want the world and they want it yesterday... and Agile empowers the scrum team to give them a reality check and say no.
I apologize for the run-on sentences... too lazy to edit at the moment.