Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.
First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.
If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.
Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.
Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.
Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.
Derrk,
1) All sprints can be halted at any time in reaction to things like the critical operational defects you mentioned. The reality is, no software development methodology would force you to ignore critical issues like an operational defect. If it did, it would never be implemented.
2) You can do this a couple of ways. As you mentioned, a defect-tracking sprint is one way of doing things. The reality is that under SCRUM you should always have a tester embedded into your team. Their responsibility is to create tests for each item on your work backlog. As items are completed, they should be immediately tested by your tester.
Now, in a modern agile environment this is usually done by your continuous integration environment. But normally, those environments don't do integration testing that well, which is where your tester comes in. AGain, remember, SCRUM teams are cross-functional, meaning they should include not only developers but also testers, CM, Requirements managers, etc. So, testing and defect tracking/correction will take place throughout your normal development sprints.
The testing sprint at the end of your development will be to validate the developed system works properly, prepare it for operational acceptance testing, deploy it into a operational test environment, excersize your system and then deployit into an operational environment.
3) Your Product Owner will be the one who determines that, and they will determine this by working with the customer as they prioritize thier product backlog. In reality, some business wonk will have signed the team up to deliver some sort of functionality by some fluid date range. The Product Owner will work with the customer to determine the degree to which that functionality should be implemented and exactly what should be included in each Sprint.
Of course, the Scrum Master and the development team will determine what they can actually develop during each Sprint and communicate this to the Product Owner. If the team provides feedback to the Product Owner that will result in a slip from the imposed time-line, it is the Product Owner's job to work with the customer to reprioritize the product backlog to take this into account.
Best Answer
Bring something from the project backlog into the sprint (after discussions with scrum master and project owner).
The size of the item you undertake will depend on how much time you have. If there is nothing small enough create a sub-task of a bigger task to get it started (ie do some of the preliminary work).
Alternatively create some tasks that make the code base better. I have never seen a code base that could not be improved in some way. Review some code add more unit tests etc..