You aren't doing Scrum. You're possibly doing something Scrum-like, but your boss needs to read The Scrum Guide, and the Scrum Master needs to take an active role in educating this manager about his role (if any) on the project.
Who Manages the Product Backlog
[M]y team's manager insists on putting stories in the sprint that are ill-defined. Mostly what the story contains is people to talk to to gather requirements....[and] my boss insists this story must be started this sprint.
Only the Product Owner may manage the prioritization of stories on the Sprint Backlog. If your "boss" (who is presumably line management) is also acting as the Product Owner, this is a conflict of interest. If he's not the Product Owner, then he's overstepping his role as a stakeholder within the Scrum framework.
Furthermore, while the Development Team must work on user stories from the Product Backlog in ordinal sequence, it is solely up to the Development Team to estimate stories and identify how many of those top stories will fit within each Sprint. In other words, you accept the amount of work you are confident that you can finish each iteration; the volume of work can never be assigned from outside the Development Team.
Requirements Gathering as Stories
It is never acceptable to have a significant scope or requirements change within a given Sprint unless the Product Owner calls for an Early Termination and a return to Sprint Planning. Having your organization violate this basic principle is a serious process problem for the team and potentially breaks the framework.
In addition, one of the biggest causes of framework failure is the inability to deliver a refined Product Backlog to Sprint Planning. The Product Owner (not line management, stakeholders, or anyone else) is responsible for delivering actionable stories to the Sprint Planning Meeting.
While it's okay for the Product Owner to work with the Scrum Master and Development Team during Backlog Refinement to clarify or decompose stories, "requirements gathering" can't pragmatically be a baked-in part of a user story; at the very best, one might add additional user stories about requirements gathering.
A good cross-functional team might have a business analyst. Even if not, as story that says something like:
As a Development Team member,
I need to discuss feature XYZ with marketing
to help define the scope of work for the feature for the following Sprint.
Whether you call this a story spike or simply requirements gathering, this is an acceptable story because it clearly makes the cost to the project visible (e.g. that requirements gathering isn't free), and allows the refined story to be fed onto the Product Backlog during Backlog Refinement to be prioritized by the Product Owner, and eventually estimated and accepted by the Development Team during some future Sprint once the story reaches the top of the Product Backlog.
Scrum Master as Educator and Referee
The Scrum Master is the process referee. When you see "framework fouls" like this, you need to pull out the red card and blow your metaphorical whistle. Furthermore, you need to provide adequate education about the framework, its defined meetings and artifacts, and the roles and responsibilities within the Scrum framework and the organization to everyone in the organization. Whether or not your boss is properly a member of the team is something I can't assess (although I suspect not), but your role as Scrum Master is to work with him to define framework-appropriate ways for him to interact with the team within the scope of the framework.
If you are unable to do that, or if he is unwilling to adapt to the requirements of the framework, then you may want to start dusting off your resume. It doesn't matter whether the problem is an inexperienced Scrum Master or a command-and-control line manager; both are key ingredients that are statistically likely to lead to project failure, and unless your job title is "Professional Scapegoat" I wouldn't stay in a situation that is likely to lead to a career train-wreck.
As always, your mileage may vary.