Splitting user stories seems to move away from the V part of INVEST

Also as an additional question:

Do you think user stories should be functional in nature i.e. the user engaging with an interface to do something.

Or do you think user stories should be used when the user wants something, but it's not actually them doing the function e.g as a marketing manager, I want the eCommerce website to display a pop up advert with a discount code when the customer exits the checkout process. 

These latter kinds of requirements just feel so strange & difficult to shoe horn into user stories, especially when you consider all the subtle pre-conditions for certain actions to be performed by the system

When you say "user story format", you seem to be referring to the Connextra format. A user story is an expression of a user's need for the product or system. "Place an order" is a valid user story, as is "Search for product by keyword" or "Filter products by brand". The Connextra format was developed years later to help teams capture some additional information, such as the actor or user class and the value proposition, in a succinct way.

There are also alternatives to user stories for cases where they may not make sense. Job stories focus on situations and expected outcomes. Problem stories focus on the underlying problem to be solved. Improvement stories focus on the desired state change from a current situation to a desired situation.

These story formats have one thing in common: they are lightweight representations of desires or changes, in contrast to heavyweight specifications that detail an entire product or system's characteristics and behaviors.

In your specific example, you identified a problem with the Connextra-style user story format. Sometimes, there are multiple perspectives needed. Either representation could be valid. Both could also be valid. For example, it could make sense to design and implement either the customer-facing side or the trade managing-facing side of the work to demonstrate and get feedback. Two stakeholder groups are interacting with the system, so you may want to build a proposed solution for each group and make sure that it makes sense. It would be up to the team to decide if they wanted to work on these items in parallel or implement one then the other, keeping in mind that they may need to use artificial data to put the system into a state that allows one side to give feedback on the design and implementation.

I see several examples of what look to be thin, vertical slices that are demonstrable work:

• Retrieve all of the products from the ERP system. Load them into your system and be able to display them. This would demonstrate the connectivity between the eCommerce engine and the ERP system, including how the engine handles changes in the ERP system. It may not be useful in production at this point, but perhaps you can get feedback on how you display items to customers and make sure your user interface is appropriate when you do add filtering.
• Retrieve all of the customers from the ERP system. Again, you are demonstrating the ability to exchange a specific set of data and how the system displays it. If you have stakeholders who need to get information about customers through the eCommerce engine, you can get feedback on what data elements you are displaying and how you are displaying them and let people interact with this.
• Build the relationship between customers and products in the ERP. If you have a display on the eCommerce engine, you can demonstrate that this relationship data is available. You can ensure that your eCommerce engine data model is appropriate for capturing and storing the necessary data and working with it.
• Add support to the eCommerce engine for filtering the data by customer account and demonstrate that only appropriate items are displayed based on the active user.

There's nothing that says that the end result of implementing a user story needs to be something you deliver to a live environment. It's more important that you demonstrate progress and get user feedback. You may need to implement an entire user flow before it's usable in a live environment, but these incremental steps can ensure that you are progressing toward the correct user flow and that your understanding of what is needed is accurate.

I guess I just dont understand how a project to implement a complex set of applications working together to facilitate business processes can be reduced to a set of user stories meeting the INVEST criteria. It makes no sense to me.

Me neither. Where work is genuinely complex, there isn't much chance of reducing it to a prescription written in any sort of format. You have to innovate instead.

What you can potentially reduce work to is a series of experiments that may be run Sprint by Sprint. Product Backlog items are elicited merely to grease the wheels of the innovation mechanism: the format they take is irrelevant. User stories are useful as placeholders for emergent conversations about requirements, but there are other means of capture. The Scrum Guide doesn't mention them for a reason.

I should start by saying I'm not the biggest fan of user stories as a format for documenting backlog items.

Not only do I agree with you but I actually advocate that they not be used.  I advocate that you capture the need and the value in whatever way makes sense for the problem space being described. But as a Scrum Master, I always defer to the Scrum Team to do what they feel is best.  It isn't my place to make this decision.  You might find this article about story points interesting.  

Now, to your point.  @Thomas provides you some very good information.  In fact, some of that I wasn't aware of.  Thanks @Thomas.  The original User Stories have evolved over time and as with all things associated to software development, they have morphed into multiple variations and permutations.  Feel free to create your own and see if you can get people to use it.  

...move away from the V part of INVEST.

One thing that needs to be cleared up is whether you are using the word "valuable" or "vertical" to represent the V in that acronym? Because I would answer the question differently based upon that interpretation. 

If it's "valuable", it is actually much easier.  All of the examples you provided were valuable in some way.  Without that capability, the product would be lacking and not something that the stakeholders would want to use/sell/support/etc.  It is not difficult to create a statement that can show value when talking about software development.  However, it is difficult for some people to understand the value so that is where the Developers have to help.  For example "As a Developer, I need to upgrade component XYZ to use version 8.4.2.1.6.8.0.4 of ThatThing."   Some of the non-developer stakeholders may not understand why that is important, especially right now and instead of addressing "As a user, I want to be able to enter credit card info to be saved so it is easier for me to buy things."  But I have never had any pushback when I have explained that without that upgrade, our product will not be secure and we cannot implement items 4-9 of the Product Backlog. BTW, this is where the "so that..." part of the User Story came to be.  

If you are using the work "vertical", things become a bit more difficult.   Sometimes vertical will only go so deep.  The trick is to tie multiple shallow verticals together to create a deep vertical.  I once helped someone understand it by having them picture a stairwell in a tall building.  Is it one long set of stairs with no breaks?  No, there are usually platforms created at and between each floor.  But a single set of stairs between two platforms alone doesn't really help much.  You have to join them to more sets in order for them to be useful.  How high/low you decide to go, how many steps in each set, how steep the climb is all up to the people designing and building the stairs.  But don't forget that in some cases, you may need a story to build some of the platforms in that process.  

In the end, define what is needed to improve the product in a way that makes sense, can be understood by the people doing the work, and understood (or explained) to the people that have a stake in the work being done (i.e. stakeholders).