This is a common confusion and only solution is identifying different perspectives.
From your question, I feel you are visualising
"adding content in the backend which ultimately displays in the
as one single story which can either be broken down into
"1. one story-two interdependent tasks"
"2. two interdependent stories"
both of the above unable to deliver anything useful if not complete in the same sprint.
Look at it this way...
There are two users involved - site admin and User(or visitor) - so it can not be a single story. It can only be a "feature".
Also, though the "feature" may not be complete, for respective users the functionality can be complete.
Look at it this way...
As a user, I don't care if the content I am seeing is hardcoded in a template, or there is a form in the backend to configure it. If I see the content in any device of my choice, the story is complete for me.
As a content author, I just need a convenient way to add/modify the content. Once I add the content, I am assuming that programmers have done their bit to display this content in proper formatting. It is not my job to do the CSS. If formatting is not appropriate, PO will thrash the developer but not me, so my story is complete.
Now which story should take preference?
Will the banner content be updated often? If no, should I just add the content in the template and prioritise the backend configuration for the banner? If yes, should I demo by end of this sprint how the backend system for the site admin look like and take up the display in next sprint? Or priority for the client(read business) is to know that their visitors can see the content in any device - I should tell them that we have made the display adaptable to all the devices and will make the content configurable in the next sprint?
User stories should never be created on technical boundaries. A good user story always solves a business case - either something that affects the end user directly(like displaying information through the banner), or indirectly(efficient way to update information in the banner).
Scrum is not about waterfall-like rigidity. Features can and they do overlap during early sprints. This will automatically sort as the product matures. If not, either the developers are not making the code modular enough or backlog needs grooming. Any of the case will surface in one of the retros.
Initially it is good to create feature completion projections. Inform the stakeholders by when they can see the complete feature. This will help in creating expectations and consequent sprint planning.
Sometimes it is difficult to isolate features in independent stories due to limitations of the technology platform or business priorities. It is perfectly normal and there is no golden rule to escape it. Until the team is demonstrating improvement after each sprint, you are on the right track.
It is important to grasp AGILE as continuously evolving product-first ideology and not another way of project management that is trending in the market.