The sub-graph is shown below. There are 4 little square cyan boxes, they are objects with type PropConnector.

Those PropConnectors are all connected to a Port in the green Skill-objects. Now I want to define the PropConnectors as dynamic ports in the (parent) Processor object.

I can do this in the Symbol Editor of the object Processor with a Template. 

When I define a generator as this I partly get what I want:

However I want the portname and Skillname to be given (as such)

But it seems this is not possible. How can I achieve this?

(Note that I'm following what you wrote, so the PropConnector rather than the Skill is the dynamic port.)

For the second part, you want a symbol for the PropConnector as a dynamic port. The PropConnector already has a blue square symbol for when it is used directly in a graph, but in the Template you can set it to use a library symbol when it is a subsymbol here: Subsymbol | Library symbol named by: Selection | ... | New. Give a name for the new library symbol and a Symbol Editor for it will open. Note that you have to OK the Template dialogs before Windows will allow you to click in the new Symbol Editor. 

Draw a Text element the same size as your dynamic port, and set it as a generator. We want to display what the PropConnector is connected to, e.g. the port name 'Src' and the Skill name 'SetStartLocation'. Our starting context was in the upper graph though, and after that on the stack we have the Processor object then the PropConnector. To get into the subgraph, we want to start from the Processor (one level higher on the stack than where we are) and go to its decomposition:

do decompositions;1 {

Now we want to navigate from the PropConnector, one level higher from where we are now:

   do ~From;1~To {

we only navigate into the To role, not the port. From the To role we can display the port's name and Skill object's name:

      do #() { '(prop ' :name; ') ' }

      do .Skill { :Name }

Say I delete all four PropConnectors. Than I have 4 Ports that have nothing connected to it. Would it be possible to create ports in the Processor-object with the exact same result as before ?

So iso using PropConnectors, identify which ports of the Skill that are not connected? I wrote a generator that can identify which ports are not connected (not have a relationship), but it seems (but not sure) I need (in the generator in the format template) to supply a id and there is no unique id for these ports (only combi Skill + Port is unique).

The benefit of this is that I just can leave the ports unconnected, iso having to connect a PropConnector to all empty ports (really the only reason why I defined a PropConnector is to be able to generate ports in the Processor). It is a small benefit but usefull.

At the moment, your PropConnector objects have no name of their own, but instead reveal the name of the port on an object in the subgraph (e.g. Src on SetStartLocation). If we follow the analogy of a function, the PropConnector should be able to set its own name, which allows better specification of the semantics of the port in the context of this graph. We could consider the signature to be (StartSrc, StartDest, TargetSrc, TargetDest). It's better that those are explicitly revealed and named — rather than just being "any port I haven't connected yet", revealing and creating a strong coupling with the internal details of the sub-object name (SetStartLocation), and a port within its subgraph (Src). 

Often, we want our languages to be scalable, allowing multiple levels of subgraphs. If we make the name displayed in an object's port to be the name of a object's port in a subgraph, then we have to ask where that lower port got its name. Presumably from a subgraph; obviously that chain has to end somewhere, with the lowest subgraph no longer connecting its port to another object with ports, but instead to an atomic object. That object will be a literal value like '3' or a local variable - and neither of those are well-suited to be the name of a port several layers higher. It's cleaner and more scalable to put the name into the 'formal parameter' - your PortConnector, which is an example of what we often call 'interface objects'. 

This approach also lets you connect an interface object in the subgraph to several ports - the modeling equivalent of using a function parameter in more than one place in the function body. That's very common, and shows up another problem if the naming is taken from the subobjects' ports: if an interface object is connected to two ports with different names, which one wins?

Your example graph above probably doesn't have all these issues, and may never need to scale up and face them. Still, these are good general principles that we've found, and hopefully give you some useful points of view to think about.