Is it correct to split user stories by user types?
Maybe. Maybe not. It really depends on your organizational context. There is no universally correct answer, but one suspects that in this case you are splitting user stories this way because you are treating stories as specifications rather than vertical slices of functionality.
Why Your Current Stories May Be Specifications
It is often best to allow the development team some latitude in determining implementation details, and to avoid creating magic numbers and technical debt by over-constraining user stories. Obviously, this must be balanced against the YAGNI principle to guard against over-engineering, but allowing flexible design within a team's self-organizing process is generally a more agile approach than detailed specifications.
When you say how many uploads per day a given user may have, the easiest thing that could possibly work might be to hard-code an upload limit on some user records. One could argue that refinements could be done in future iterations, but one could also argue that this is unnecessary technical debt.
Truly iterative development doesn't ignore the design and architectural phases of product development. Rather, it encourages a just-in-time (or perhaps a "just enough") model where teams do sufficient planning to complete the features within the iteration with a minimum of technical debt.
The stories you have, as currently constituted, spell out how the feature is to be implemented, rather than describing a missing feature (e.g. the ability to define upload limits) or explaining how the feature adds value. This may be perfectly acceptable in some cases, but overuse of stories as specifications can inhibit agility.
User Stories, POV, and Verticality
User stories should definitely have a point of view, but the POV need not actually be the end user. For example, both of your stories may be addressed by a common story, such as:
As the marketing/sales director,
I want user upload limits to be set by some sort of permissions table
so that we can monetize our freemium model.
This story would probably get you to the same place as the stories in your original question, but has a different focus. The change in point of view provides the story more flexibility in its implementation (e.g. what if you wanted a third tier of bandwidth?), and provides a clearer statement of value and more context to guide the implementation details.
Note that this counterexample doesn't mean your original stories were "wrong." The point is that you should split stories up in any way that makes sense for the team and creates a deliverable unit of value. However, limiting stories to functional specifications often creates artificial constraints, so it may be useful to consider higher-level goals when deciding on how granular to make a given set of stories.