首先，您正在使用过时的文档：RFC 2616现在已不再相关，任何使用此文档作为参考的人应该立即停止。
引用马克·诺丁汉（Mark Nottingham）的话，在撰写本文时，他是IETF HTTP和QUIC工作组的联合主席：
不要使用RFC2616。从硬盘、书签中删除它，并烧掉（或负责地回收）任何已打印出来的副本。
旧的RFC 2616已被以下文件取代，这些文件共同定义了HTTP/1.1协议：
如果你正在寻找方法、状态码和头部定义，那么你应该参考RFC 7231这份文档。
说了这么多，让我们回到你的问题。
如果资源不存在，HTTP PUT 应该创建它吗？
这取决于情况。
但是，如果您的应用程序代表客户端生成资源标识符，就像您在问题中提到的那样，那么您应该使用POST而不是PUT来创建资源。
以下是PUT方法定义的一些部分。最后一句似乎与您最相关（我突出了重点），支持我刚才提到的内容：
4.3.4. PUT
PUT方法请求使用请求消息有效载荷中封装的表示定义的状态创建或替换目标资源的状态。 [...]
如果目标资源没有当前表示并且
PUT成功创建了一个，则原始服务器必须通过发送
201（已创建）响应来通知用户代理。如果目标资源具有当前表示并且根据封闭表示的状态成功修改该表示，则原始服务器必须发送
200（OK）或
204（无内容）响应以指示请求的成功完成。[...]
正确解释
PUT请求假定用户代理知道所需的目标资源。
在接收到更改状态的请求后，代表客户端选择适当的URI的服务应使用POST方法而不是PUT。[...]
如果创建资源不可能，我应该返回
404错误吗？这似乎是一个准确的状态码，因为没有找到所请求的资源的表示形式：
6.5.4. 404 Not Found
404（未找到）状态代码表示源服务器未找到目标资源的当前表示形式或不愿透露存在该资源。[...]
现在，为了完整起见，请查看以下关于
POST方法定义的相关引用，该方法应在您问题描述的情况下用于创建资源：
4.3.3. POST
POST方法请求目标资源根据资源自己的特定语义处理请求中包含的表示。例如，POST用于以下功能（等等）：
[...]
[...]
如果作为成功处理POST请求的结果在源服务器上创建了一个或多个资源，则源服务器应发送包含Location头字段的201（已创建）响应，该字段提供主要已创建的资源的标识符并引用新资源的状态。
当201状态码表示新资源已创建时，Location头部指示新创建的资源的位置。如果未提供Location头，则客户端应假定资源由有效请求URI标识：
6.3.2. 201 Created
201（已创建）状态码表示请求已被满足并导致创建一个或多个新资源。请求创建的主要资源通过响应中的Location头字段标识，如果未收到Location字段，则通过有效请求URI标识。[...]
- PUT 方法是否可以创建不存在的资源。
- 生成数据库 ID 应该使用什么方案。
我认为回答第二个问题（自己）是决定 RFC 给出的选项的关键。 - kosgeinsky