If you need to make invalid markup, consider a plain text field. Not sure how much this would change your existing extension and content model, but you can enter anything into a plain text field, including what seems to be some kind of "split" or dividing placeholder.
</div><div class='Page'>
To keep rich text functionality and follow some typical Tridion practices, consider one of the following.
Complete all the markup changes at once
Assuming your final markup will have an open <div> and closing </div>, considering making your extension wrap an entire set of selected rich text. In the process and before updating the component, allow the author the ability to pick the location of the "split" and save the entire update to the RTF.
Create "splits" with embedded schemas and Template code
Embedded schema fields are a much easier way to split content. Authors create a new set of embedded fields and template code can change that to tabs, paragraphs, or what might be pages (pagination?) in your case.
A "Paragraph" embedded schema can handle this use case, as I understand it.
<!-- TemplateBeginRepeat name="Component.Fields.Paragraph" -->
<div class='Page'>
<!-- author-entered content -->
</div>
<!-- TemplateEndRepeat -->
This will create the </div><div class='Page'> in-between sets of embedded fields. It also lets you change the class and tag in the future without extension changes.
Insert Non-HTML "Merge Fields" Instead
See options on a post I wrote about custom tags in rich text fields, which include:
- CSS classes in the Content Manager Explorer such as
class="page-split". You can even style this to look a certain way (visually as an <hr/> for example), then template it to whatever you need in the final markup.
- Merge field placeholder tags such as "
[[end-page]][[start-page]"
- Custom HTML5 nodes, if you must
You can insert any of these with an extension, optionally styling them to look a certain way in the CME.
I like giving authors easier ways of inserting functionality within rich text fields, but the catch with inserting specific HTML, especially invalid HTML, into components is in hard-coding this functionality into the content. You'll run into issues with migration and design changes.
Consider taking advantage of how Tridion separates design from content.
