Stories are really supposed to be functional with business value, so your concern is justified.
We have used technical stories, such as "As customer, I can send data via web services...." because we needed to build integrations to/from an ERP and I couldn't figure out a way to phrase it as functional/user. They should be the exception, not the rule.
For the spike justification, show him this: http://blog.agilebuddy.com/2009/11/...crum.html,
from a "agile spike" internet search. Spikes IMO are more Proof of Concept than design.
The BA is the Product Owner? Try to find out (in a collaborative way) WHY he/she needs the overall design. What business value does it provide? Is it because there are interdependencies between the groups (which would be a good reason but maybe there's another way to accomplish that beyond document everything).
I mean, "Working software over comprehensive documentation" is in the agile manifesto...
OTOH, when there are dependencies with other teams, my team expects some kind of documentation before they start working on it, so the pieces work together. In our case it's an integration specification (in web services example request/response is defined before coding, although it can and does change during implementation).