This is currently not possible in Craft. You can group fields into field groups, but those are only used for organizational purposes.
If you care about this feature, you can suggest it as a feature request in the discussion section on Github. This allows other people to upvote the idea – a feature request with lots of upvotes is more likely to get implemented in future versions of Craft.
If you only care about speeding up the creation of new entry types with a common set of fields, there's already a feature request to allow batch editing in the field layout designer. If this is what you're going for, make sure to upvote the feature request and provide ideas on how this could be implemented. Perspectives of developers coming from other systems are always great for this. This feature could be integrated with the existing concept of field groups – for example, by providing a single button to add all fields in a particular field group to the field layout.
In some systems there's another 'flavour' of field groups, where the group isn't just an organizational taxonomy, but acts as an extra layer between an element and the grouped fields. In your example, you could create a field group
header which is comprised of a set of nested fields and can be added wholesale to field layout. In this case, the fields would usually be accessed as
entry.header.headline instead of
entry.headline. This has the nice benefit of allowing you to use the same field multiple times in the same field layout, by nesting them in different groups. Also, you can modify the field group in one place and any changes immediately apply to all entry types where the field group is used.
This isn't currently possible in Craft – if you want something like this, maybe post it as a separate discussion. I'd certainly upvote it, as it's something I'm missing as well.
For reference, ProcessWire provides a FieldsetGroup field as part of the commercial ProFields module which works exactly like that.
Another option for right now is to make your content more granular, reducing the need to put the same fields in multiple enty types. In your example, you could create a section
header with an entry type that contains all your header fields. Then your editors could create
header entries separately and associate them with a particular page using an Entries field. Using this approach, only one entry type needs all the fields you need for your header group, and all entry types that need to have a header just require the entries field. Conceptually, this is close to the field groups mentioned above.
Of course, whether this makes sense depends heavily on context. In this example, it would enable header reuse but make editing a bit more indirect and cumbersome. It's all a matter of trade-offs.