How to handle story that cannot meet the definition of DONE at sprint end

Why doesn't the team want to break the work into smaller units?

Scrum prescribes that Product Backlog Items become ready for selection when they can be Done by the Scrum Team within one Sprint. My preference, also based on my experience, is to go smaller - it is better if a Product Backlog Item can be something that the team can get to Done and then deliver or demonstrate to key stakeholders in a couple (2-3, at most) days.

I would want to understand why the team isn't refining and decomposing this work into smaller chunks that can help the team ensure they are building the right thing. What would happen if, after three Sprints, they show all this work to a key stakeholder and they built the wrong thing? How can they show progress with the work if it takes 3 Sprints to get it to Done?

Scrum is not some sort of reductionist process where large pieces of work are chunked down for delivery in Sprints. Scrum is about learning to build the right thing at the right time.

How can the team reduce the leap-of-faith they are taking in this work before they get an empirical outcome, and assumptions about it are validated? That's the challenge.

I've faced this before.  The real reason that the Developers didn't want to break it down further was because they didn't fully understand their solution and couldn't visualize a way to break it down.  I suggested a couple of "spikes" to try out some potential solutions.  They were able to do two spikes in a single Sprint and discuss solutions with the stakeholders. They were then able to break it down into smaller deliverables.  It took an extra Sprint to get that information but they were able to deliver the solution in two parts across 2 additional Sprints (i.e. 3 Sprints total). So in the end it didn't save much time but it did allow them to get feedback sooner and it included the stakeholders in the decisions. 

As usual, I agree with everything that @Thomas and @Ian have said.  But I will offer another suggestion.  Let the Developers do the work as they want across 3 Sprints.  However let them know that in every Sprint Retrospective the progress needs to be a discussion.  When they do finally deliver, there should be some detailed, honest discussion about the work to identify if they could have handled it differently.  Make sure that they inspect, adapt, repeat. 

Thanks all for the responses. 

@Daniel Wilhite, the developers feel that the story is complex as it involves a lot of database work which only one developer should undertake after initial investigation was completed. Development work alone is estimated to last 2 sprints. Since there would be no release until June, the PO is happy to go ahead with the developers suggestion of how to handle this particular story. This situation is not a regular occurrence but an exception as the highest story points normally allowed in a sprint is an 8.