TL;DR
This is fundamentally an X/Y problem. The unspoken premise missing from your original post is presumably that your clients don't want to pay for "idle" resources, but that's really just a straw man argument that obscures the lack of collaboration between your teams and the I-shaped people that compose them.
The team needs to self-organize around a predictable delivery cadence that provides a potentially-shippable product increment every single Sprint, and meets its Sprint Goals the vast majority of the time. If you're not doing those things, you're not actually doing Scrum.
If you have a very large project, you probably need to look at some form of scaled agile framework such as Scrum-of-Scrums, Nexus, LeSS, or SAFe. That won't really change anything below, but it may address some of the integration and collaboration problems you're having with multi-team workflows.
JIRA is a Tool, Not a Framework
Your question includes the jira tag. JIRA is a ticketing system, not an agile framework. While it may help you track work or meet reporting requirements, it isn't a substitute for a properly-implemented agile project management framework.
Allowing JIRA to drive the implementation of your Scrum framework, rather than supporting the framework's requirements, is a well known anti-pattern. Once you've identified the necessary workflows to meet your project's objectives, JIRA should be configured to support that workflow. Doing it the other way around is tantamount to the tail wagging the dog.
JIRA can certainly support Scrum implementations. However, if you find the process contorting itself around JIRA (or any other tool), then the tool is the problem. Either find a way to integrate the tool with your desired workflow, or discard the tool for something that's a better fit.
Respect the Time Box
Your question is tagged with scrum, so all Product Backlog Items (PBIs) pulled into the Sprint Backlog are expected to fit within a single iteration. If the stories won't fit, they need to be deferred, refactored, split, re-scoped, sliced differently, or otherwise reworked so that a cohesive Sprint Goal can be delivered at the end of each Sprint.
The goal of a Sprint is to deliver the Sprint Goal. If you don't have a clearly-defined goal, or can't routinely deliver an increment of work at the end of each Sprint, then you aren't really doing Scrum. That may be okay, but please recognize that what you're currently doing is really just Scrum-But at this point.
If your teams can't or won't follow the framework's requirements, then Scrum may not be the right framework for your project. No one outside your organization can decide that for you, but some soul-searching about why your teams are doing ersatz Scrum, and whether that's leading to the results your company wants, is probably in order.
Co-Dependent Teams and Excessive Rework: Just Say "No!"
Features can certainly be split into front-end and back-end pieces, but it will require you to think about the problem domain and the solution space differently. It may also require you to stop thinking of your teams as delivering on a single, cohesive increment.
By splitting work across teams, work often becomes a game of ping-pong rather than a fully-collaborative effort. For instance, the back end team builds a model, the front end team builds a view to expose the model, and then the teams toss work over the wall to one another to refine the separate implementations.
This can certainly work, but each step or hand-off in your process creates friction, overhead, and potential rework. In an iterative process, refactoring and rework are expected as the product is refined over time. However, baking the need for refinement into your process creates a layer of co-dependency between teams that usually leads to externalizing dependencies rather than active collaboration. This creates needless technical debt and slows velocity for no discernible gain.
Just like test-first development involves testers before, during, and after code is written, back-end and front-end work should involve both types of work ab initio so that the final product reflects the emergent design of both aspects. Otherwise, you create a scenario where one team or the other builds something without taking the other team's skills and requirements into account.
- "Here's my model, build a UI around it." This constrains the solution space for the front end developers, and often requires rework by the back end developers to accommodate front end changes.
- "Here's a UI wireframe. Build me a back end to match." This constrains the back end solution space, and often requires contortions that abuse SOLID principles or require ugly hacks to support UI elements that aren't natively expressed by the current domain logic.
- "I did this thing last week. Please make your stuff match this week. Then I'll have to fix a bunch of stuff that you break next week." This obvious anti-pattern needs no further explanation.
In short, iterative development implies a certain amount of rework and refactoring, but ping-pong development just slops on an unconscionable amount of it for no demonstrable benefit. Hence, the agile focus on collaboration over rigid process and work silos.
Clients Value Outcomes, Not Effort
The final thing to consider here is that transparency (a core Scrum principle) doesn't require over-explanation or whitewashing of the process. Agile organizations don't need to cloak what they're doing in ersatz productivity (more correctly pronounced "busy work") to justify what they're doing.
Scrum is based on fitting variable scope (the Sprint Backlog) into a fixed time box (the Sprint) with a predictable run-rate (the average cost for each Sprint) to achieve milestones (the Sprint Goals) that lead to an acceptable product. In other words, a Scrum Team costs X dollars per Sprint, with an estimated N Sprints to reach a release target. The project sponsor gets a chance every single Sprint to evaluate the project to determine if it's "good enough" as is, whether more Sprints are required, or whether the project should be killed off as a sunk cost.
The client should focus on the delivered increments and product goals, and can weigh in on whether the running cost of the project is delivering sufficient value or not. Focusing on the utilization of team members, or in fact on anything other than the incremental delivery of business value, is inherently non-agile. It's a holdover from Theory X management, and selling agile projects based on other than predictable delivery of observable increments of value (such as per-person labor costs) is largely self-defeating for everyone involved.
Clients should care whether the weekly run rate is delivering sufficient value for their purposes. Clients should not care whether Alice and Bob are on the same team, different teams, or snowboarding in the Himalayas, so long as the product increments are routinely providing sufficient perceived value for the money spent.
The outcome of each Sprint is what delivers potential value. The Scrum Team's internal process should be largely irrelevant. If that's not the case for your project, neither the organization nor the client have been sufficiently educated about the trade-offs inherent in agile processes.
