Big stories planning

I've never seen a unit of work, story or otherwise, that could not be decomposed into smaller, demonstrable work pieces. I have seen very complex work that could not be delivered until it was complete. However, there were still smaller units that the team could design, implement, test, and demonstrate to stakeholders to validate their direction and ensure that it would be the right thing when it was ultimately delivered. I would strongly recommend spending more time thinking about how you can decompose the work to get feedback, even if it means it can't be delivered or deployed on its own.

Part of the issue may also be the separation between development and testing. Having a handoff from a developer to a tester often makes the work more complicated, which slows it down. Sometimes, this slowdown is enough to prevent a unit of work from being done within a Sprint. Although this kind of organizational shift can be hard, getting away from separate developers and testers can lead to lower cycle times for work.

Both of these do take time. It takes time to teach teams about good work decomposition strategies, and product architectural and technical debt may make it hard to implement those good decomposition strategies until the underlying issues are resolved. It also takes time to teach people cross-functional skills, enabling developers to become proficient enough to test work without a handoff. In the meantime, you may have to have work that doesn't fit into a Sprint timebox.

The Scrum Guide says "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint."

In the situation you describe, that would not be happening. Nothing would be finished, and no empirical experiment would be conducted that Sprint.

Think about the smallest experiment you could run which would help validate the emerging Product, and frame a Sprint Goal around that purpose. The work on a Product Backlog is there to enable these discussions.

Development Sprints and Testing Sprints are an antipattern. If a team can't meet their Definition of Done, and I am assuming you have one that outlines all the quality measures necessary for the work to be done, the gaps to getting to done should be made transparent, and the team should use the Sprint Retrospective to discuss those gaps.

Why not teach the team to commit to a Sprint Goal rather than a 'story', and coach them to use their creativity to meet the desired outcome?

To add to the discussion, in the rare case where a work item truly cannot be broken down further, teams might consider horizontal or vertical slicing as a technical strategy.

Horizontal slicing involves implementing one layer at a time—say, starting with the database layer. Testing and review could be done via database tools. Vertical slicing, more in line with Scrum principles, means implementing a small piece of the functionality across all layers of the stack, making it testable and potentially shippable.

That said, if this situation arises frequently, it may indicate a need to revisit story decomposition techniques during backlog refinement. I have only ever encountered one case where decomposition was not feasible, and a horizontal slice was used—but it was followed quickly by vertical integration, and the stakeholders were informed ahead of the Sprint Review.