Doubt as to the structure of a use case

About your doubts let's answer them in parts.

Is signing up a proper name?

In the general theory of use case structure, we use names with verbs to determine that some task will be performed, this is not a rule, but it is considered good practice within the UML.

Let's go to the following example, we have a hypothetical scenario.

A factory has some workshop parts to be sold and needs to be delivered to the customer, who owns a workshop. If you put only "parts" in your diagram you can not understand what it is. There are a lot of possible actions to do with parts, such as deliver parts, buy parts, sell parts.

As stated above, the ideal is to put a verb to indicate what action is going on.

So register, register, register is an ideal name

In the above case is it correct to have the element CRUD?

No, it is not correct to have the CRUD element, within the use case, we do not represent system functionalities, in a system-level way. For that there are other diagrams, like the one of classes, in the diagram of use cases we only represent the actions that an actor will do.

As demonstrated in the previous example, we should only show in the use-case diagram the actions made by the actors, not the features of these actions.

Manage user should be Keep user? I did not understand this question, have to see your scenario

This include find me dispensable, should I remove? To know whether we should remove or not, we must once again enter into the use case theories.

Include

In the use-case diagram, the include element is used when one feature is totally dependent on the other, ie it is mandatory. Explaining it better, let's take an example.

Generate Nota Fiscal would be a Make Include include.

The invoice can only be issued after a sale and mandatory, it can not be optional.

Extends

The extends, is used when there is also a dependency, but this dependency is not mandatory, functionality can occur independently of the other.

Explaining better, let's take an example

Send invoice by email would be extended to carry out sale.

Tax invoices can be sent by email, but not necessarily.

Answering your question

It will depend on your scenario, your exercise, you can not say for sure if you are wrong or not.

Theoretical response.

You do not have one use case, but several.

There is nothing wrong with registering.

Logging in is not typically portrayed as a use case, according to the definition of a use case (bringing a concrete benefit to an actor). It can be a step of a use case. Note: some portray yes as a use case logging in.

It does not make sense for a use case to extend a CRUD, because I at least do not see a CRUD as something generic that can be extended.

(This is the part I'm less certain of) Search also seems to elude me from something that brings a concrete benefit, but I may be wrong. In any case I believe that the idea of include is to include scenarios that are common to several use cases. I do not see Search making much sense on its own.