It seems that you are confusing stories and tasks.
A user story is a complete "feature", something that when added to the product, provides more value to the product.
A user story should not be larger than it can be implemented during a sprint. During the first part of sprint planning, you decide which user stories you want to work on during the sprint. The goal of the sprint is to complete these user stories, thus adding more value to the product.
During second part of the planning phase of the sprint, developers divide the story into tasks. The tasks are development tasks. They could be stuff like "Add column to database", "Extend service x", etc. A task should not be larger than it can be completed in one day.
During the daily scrum you evaluate the progress of these tasks. If a task has been in progress for more than one daily scrum, it is taking too long, and you, as a team, has the responsibility of resolving that situation.
Remember, user stories represent business value for the stake holders. The stake holders should be interested in the completion of the user stories, not tasks.
The task division is a tool for the development team to manage the sprint, to monitor progress of the user stories during a sprint, and to visualize potential problems.
The stake holders should not concern themselves with these development tasks. Unfortunately, it is my experience that they often do, particularly for organizations new to agile development. Dealing with this situation is a different matter though.
If a user story is bigger than you think you can complete it in one sprint, it is called an epic. It needs to be divided into several smaller user stories before you as a team can start working on it.
Remember that a user story adds value to the end user, so splitting an epic into a "front-end" and a "back-end" story is not the right way. Adding the back-end for a new feature does not in itself provide value to the end users.
Dividing an epic into user stories manageable within the time frame of a sprint is not always easy when you are not experienced with doing so.
Using Pivotal Tracker
I think Pivotal Tracker is a great tool for tracking user stories. But it is not a scrum tool as such, and the way that scrum teaches to divide stories into tasks is not easily handled by pivotal tracker. You can enable the ability to add tasks to user stories. But if you are running a project using scrum, I would suggest using a white board and sticky notes to track the progress of tasks during a sprint.