This is a pretty typical dilemma for first time BDDers (or me when I started at least)
Personally, I would use the actual first name in the step. You've already said that the scenario is the happy path, so if you had
I want to get access to the web application
With scenario Happy Path
Given I enter the first name "Rob"
And I enter the last name "FE"
Then that would be easier to reuse than before with the ultra-descriptive method names, and could possibly make more sense to a business analyst (because what defines "correct"?)
And I provide the compulsory email which is not already in the system
I would go with
And I provide the email "firstname.lastname@example.org"
Later, when you wanted to test that emails were unique you could have
Given someone else has signed up with the email "email@example.com"
When I provide the email "firstname.lastname@example.org"
In terms of hiding detail, one thing I've found useful is aggregating steps. For example, you could create a new method called "AValidLogin()" in which you call each of the given methods (directly) that you gave in your example. That way, the "happy
path" scenario will be able to describe exactly what a valid login is, but then subsequent scenarios can "abbreviate" that into a single step. Does that make sense?
StoryQ is all about communication, recording and maintaining requirements for developers to work from :). Don't be afraid to just get stuck in, it's relatively easy (and definitely recommended) to refactor as you go (Note that the text converter is meant
to be a once-off thing: StoryQ users maintain C#. If you want to maintain text files then specflow is excellent, but you don't get refactor support ;) ).
Does that help?
Finally, why not show this text (maybe as the output from a test run) to a real user / BA? BDD is all about having a common language...